# Pattern Admission And Review Criteria

Status: review checklist refreshed for NK-WP-0010

## Purpose

This checklist controls how new patterns enter and graduate inside the
security architecture pattern infospace.

NK-WP-0010 admitted every exact pattern named in the genesis catalogue as
`seed` or stronger. The next reviews should focus on evidence quality and
maturity promotion rather than admission.

## Lifecycle

```text
seed -> draft -> reviewed -> canonical -> deprecated
```

## Admission Criteria

### Seed

A pattern can enter as `seed` when:

- it describes a recurring security architecture problem;
- it has a source, observation, workplan, incident, or external reference;
- it is clearly not just a one-off implementation note.

### Draft

A pattern can move to `draft` when it has:

- problem;
- context;
- forces and tradeoffs;
- solution sketch;
- known failure modes;
- related capabilities;
- initial NetKingdom or ecosystem mapping.

### Reviewed

A pattern can move to `reviewed` when it has:

- threat-model clarity;
- vendor-neutral framing;
- at least one open-source or self-hosted implementation option when
  possible;
- commercial/provider options where relevant;
- operability notes;
- audit hooks;
- failure-mode behavior;
- readiness-level fit;
- owning repo or component named;
- evidence needed for verification.

### Canonical

A pattern can move to `canonical` when:

- NetKingdom architecture accepts it as the recommended pattern;
- implementation anchors exist or are intentionally scheduled;
- one or more workplans, ADRs, tutorials, or runbooks point to it;
- the pattern has clear prohibited alternatives or anti-patterns;
- verification evidence has been captured at the intended readiness
  level.

### Deprecated

A pattern moves to `deprecated` when:

- it is replaced by a stronger pattern;
- implementation experience shows the pattern is unsafe or too costly;
- platform direction changes;
- vendor or technology assumptions no longer hold.

Deprecated patterns remain visible with their reason and replacement.

## Review Checklist

| Criterion | Question |
| --- | --- |
| Vendor neutrality | Can the pattern be understood without committing to a single product? |
| Threat model | Does it name the realistic failures or attacks it reduces? |
| Ownership | Are platform, product, tenant, and provider responsibilities clear? |
| Operability | Can an operator deploy, monitor, rotate, and recover it? |
| Auditability | Are security-relevant events and correlation ids defined? |
| Failure behavior | Does it fail closed or document controlled exceptions? |
| Readiness fit | Is RL0-RL4 applicability explicit? |
| Evidence | What proves implementation is correct? |
| Anti-patterns | What common unsafe shortcuts are prohibited? |
| Tutorial handoff | Does NK-WP-0009 need a tutorial for it? |

## Current Canonical Candidates

- STS credential vending.
- Secret zero avoidance.
- Delegated authorization.
- Break-glass access.
- Short-lived credentials.
- Policy Decision Point / Policy Enforcement Point.

These are candidates, not automatically canonical. Each still needs the
checklist evidence before the infospace marks it canonical.

## NK-WP-0010 Review Backlog

Use `artifacts/generated/research-pattern-normalization.md` as the
backlog for maturity promotion. Strong first review candidates are:

- Central Identity Provider and Identity Broker, because they shape
  key-cape/Keycloak integration.
- Tenant Membership Boundary and Tenant Context Propagation, because
  they protect multi-tenant correctness.
- Policy-as-Code Admission Control, Pod Security Baseline/Restricted,
  and Signed Image Admission, because they form the platform deployment
  gate.
- Security Event Taxonomy and Tenant Audit Log View, because they define
  what can become tenant-visible evidence.