3.7 KiB
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
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.