Composable Archetypes & Strictness Lattice
Repository configuration is modeled as a bounded Join-Semilattice: $$\mathcal{P}_{\text{resolved}} = \mathcal{P}_1 \sqcup \mathcal{P}_2 \sqcup \dots \sqcup \mathcal{F}_n$$
Lattice Resolution Rule: "Highest Standard Wins"
- Complexity Limits: Evaluated as the greatest lower bound ($\min$).
- Review Approvals & SLSA: Evaluated as the least upper bound ($\max$).
- Linters & Features: Cumulative deduplicated set union ($\cup$).
- Memory & Error Unwraps: The stricter setting wins (ZeroFrameMalloc, StrictBan).
Layer Order
Text description
- Layers, folded in this order: 1. Defaults (builtin:defaults-v1), 2. Pinned profiles (.config/archetypes, lock digest), 3. Pinned facets (.config/archetypes/facets, lock digest), 4. External (fleet, org, deployment, workstation), 5. Repository complexity (.standards.yaml overrides.complexity), 6. Audit compat (builtin:audit-compat-v1, if Audit set).
- Boxes: Lattice join (ResolvePolicy), Control overrides (branch protection & supply chain), Effective policy (EffectivePolicy, sealed), Consumers (audit, adopt plan, devcontainer, workstation).
- Layers, folded in this order → Lattice join → Effective policy.
- Control overrides → Effective policy (ApplyOverrides) → Consumers.
- Scenario 1, defaults: The join starts from the built-in defaults. newEffectivePolicy seeds the result with DefaultPolicy.
- Scenario 2, pinned profiles: A profile joins only through its .standards.lock pin. pinnedLayer rejects a file whose digest differs from its lock pin (ErrLockDigestMismatch) or whose id changed. native-gpu-systems then contributes its complexity caps and controls.
- Scenario 3, pinned facets: Facets pass the same pin check and fold in after the profiles. security:high adds two required reviewers, SLSA level 3 and two linters.
- Scenario 4, external, repository, audit: These layers add complexity limits and operator settings, never controls. Selected fleet, organization, deployment and workstation files fold in, in that order. The manifest's overrides.complexity joins as one more layer. When Audit is set, as in audit and adopt, the audit-compat ceiling folds in last.
- Scenario 5, join: ResolvePolicy joins every layer in order. Join keeps the lowest positive complexity cap, the higher reviewer count and SLSA level, true over false, strict_ban over allow_with_comment, and deduplicated unions. ArchetypeControls.validate rejects review_mode on every layer, so the joined policy keeps the independent default.
- Scenario 6, control overrides: Repository branch and supply-chain overrides apply after the join. finishEffectivePolicy applies only branch_protection and supply_chain through ApplyOverrides; review_mode may relax to single_maintainer here and nowhere else.
- Scenario 7, consumers: The sealed effective policy drives every consumer. standardsctl audit, adopt plans, devcontainer and workstation install each resolve policy through this loader. ResolveDevContainerFeatures re-reads the pinned files: one feature identity with another tag, digest or options fails closed.
ResolvePolicy folds the layers in a fixed order: the built-in defaults, the profiles and
facets pinned in .standards.lock, the external fleet, organization, deployment and
workstation layers, the repository's overrides.complexity, and, for an audit, the
audit-compatibility ceiling. A profile or facet whose file no longer matches its lock digest is
rejected. The repository's branch-protection and supply-chain overrides apply after the join
(ApplyOverrides), so they can only tighten it; review_mode may relax to
single_maintainer there and nowhere else.