Commit graph

3 commits

Author SHA1 Message Date
0efa06fe5c Security Layer Model v0.5 — four reviews, nine changes
All four reviewing repositories returned findings on v0.4 and one contested a
rule. Every change below came from a reviewer, not from gate-house.

- §9.1 split into `pending` (no route, capability zero) and `declared-gap`
  (route exists under §5.3, capability works). v0.4's single mark would have
  forced a false "pending" onto ops-warden's production SSH issuance —
  the fix was worse than the defect, and the defect was in this section.
- §9.3 rewritten. flex-auth contested it and was right: it collapsed "engine
  reachable but degraded" with "engine unreachable", and the second has no
  evaluator in the path to express anything. Input degradation is the engine's;
  unreachability is the consumer's, bounded by a declared auditable total
  stance — which ops-warden ADR-0009 already satisfies. v0.4 had ruled against
  shipped behaviour in a repository that assented to it.
- §5 scoped: "Tooling-layer system" means a §4 Tooling row. Without this every
  Staff repository was in undeclared violation for writing progress events.
- §9.4 requires the outbox to be local — no synchronous audit-core dependency
  inside the state-change transaction, so an audit outage cannot block a
  revocation.
- §9.5 forbids compiling maturity levels into registry content while decision
  provenance carries no registry-snapshot digest.
- §9.6 gained load-bearing versus attributive evidence, the mirror rule that
  absence is not evidence of non-occurrence, and kings-guard's finding that
  suppression biases posture optimistic and silently.
- §11 gained a fourth state: blocked-clean, which MUST NOT rank below
  conforming. A repository that declined a break-glass path and left a
  capability at zero complied at cost; one that quietly opened a client and
  declared nothing did not.
- §11 gained a machine-readable declaration form; ops-warden's layer.yaml is
  the reference implementation.
- §13 gained state and owner-status columns; access-engine's decline of
  authentication evidence is recorded.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2564823@bnt-lap001
Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9
2026-08-29 02:54:25 +02:00
2aaf46ce95 Amend §11: who must declare, and what a declaration is
Conformance sweep across the §4 catalog found two defects in this standard.

§11 required every catalogued repository to declare its layer in INTENT.md,
which OpenBao cannot do — the estate catalogues it but does not author it. That
is the §9.1 defect applied to conformance rather than capability: a rule
assigning an obligation the holder cannot discharge. For components the estate
does not author, the catalog row is the declaration.

§11 also did not say what a declaration is. A layer stated about a repository
by another repository is not one. The nine repositories carrying gate-house's
layering review note appear to declare a layer, but the words are gate-house's
and sit above a line admitting the body is unadapted — assertion, not assent,
which is the pattern this estate rejects.

§14 now records the honest count: seven of fifteen estate-authored repositories
have declared in their own voice. Adoption is not claimed on the basis of notes
gate-house wrote into other repositories.

Amended in place rather than versioned: v0.4 is proposed and unassented.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2564823@bnt-lap001
Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9
2026-08-28 23:01:35 +02:00
584738bd9f Security Layer Model v0.4 — audit-core assent and its corrections
audit-core assented to the approval evidence half with conditions and
corrected the rationale twice. Both corrections were against wording this
standard had taken from that repository's INTENT rather than its contract.

- §4 catalogues audit-core as an Engine, on its own declaration. v0.3 named it
  as an owner in §9.4 and §13 without listing it — a §11 defect in the standard
  itself, which audit-core raised.
- §9.4 rationale rewritten to cite docs/integrity.md rather than INTENT
  principle 6: an in-database chain detects a rewritten payload only if the
  attacker does not recompute the suffix, which a database owner can, and even
  with external attestation the store is not WORM or object lock. tamper
  evidence is conditional on live preconditions.
- §9.4 gained emission atomicity as approval-engine's obligation, and the
  prohibition on audit-core exposing an approval-validity query — a boundary
  audit-core stated unprompted, applying §6.1 to itself.
- §9.6 added, estate-wide: evidence proves alteration and truncation, not
  omission at source. A suppressed revocation leaves the chain intact and
  verification reports intact. "The audit record proves it happened" is unsound
  and is replaced with the sound form.
- §13 gained two gaps: stronger approval custody (unassigned — deciding whether
  approvals need archival custody distinct from other sources is doctrine work
  not yet done) and emission atomicity (approval-engine).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2564823@bnt-lap001
Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9
2026-08-28 22:54:50 +02:00