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

README.md

@@ -12,7 +12,7 @@ The dynamic, self-optimizing security platform is the long-term direction in
 ## Orientation
 
 - [SCOPE.md](SCOPE.md) — what this repo owns, current state, and when it is relevant
-- [Security layer model](canon/standards/security-layer-model_v0.3.md) — how the
+- [Security layer model](canon/standards/security-layer-model_v0.4.md) — how the
   security estate is layered (Taxonomy / Tooling / Engines / Staff) and what each
   layer may own
 - [Security scenario composition](canon/standards/security-scenario-composition_v0.1.md)