From 08cf036f3d1b6ff9a541d83e9f4c8ef625393665 Mon Sep 17 00:00:00 2001 From: tegwick Date: Sun, 6 Sep 2026 08:11:45 +0200 Subject: [PATCH] Draft the v0.8 amendment set (T01, T02, T05, T07) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Exact normative text for all six amendments, section by section against accepted v0.7, at docs/amendments/v0.8-amendment-set.md. Each carries its defect statement, its replacement wording, and the decision or contract that already governs its implementers — the statute move does not decide any of them again. A1 §9.7.3 corrects the consume ordering: v0.7's stated order leaves the CAS able to prevent only the second record and never the second side effect, which makes single consumption theatre. A2 adds the §11 emission-guarantee check so GH-IN-0001 cannot recur unnoticed. A3 keeps the §13 tables and transcribes the four stance-map rows, ops-mason's gap included, since the register migration is conditioned on an export. A4 lands the recomputability boundary with the criteria-grounding clause. A5 generalizes validation-by-owning-layer into §6.4 and adds the validating-is-not-re-issuing demarcation to §8. A6 replaces §17's stale "neither has assented" paragraph. Deliberate omissions are recorded rather than left silent: §12's fourth step is a status not an amendment, §16's reconciliation is assembly work, and no §4 catalog row moves. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01WtJBr77gMFLrN93iEevqQJ Assistant: claude-code Assistant-Model: opus Assistant-Process: 425128@bnt-lap001 Assistant-Session: f5944d8b-dac4-4e1a-87eb-8b3d8f314a63 --- docs/amendments/v0.8-amendment-set.md | 288 ++++++++++++++++++ .../GH-WP-0003-statute-v08-amendment-set.md | 5 + 2 files changed, 293 insertions(+) create mode 100644 docs/amendments/v0.8-amendment-set.md diff --git a/docs/amendments/v0.8-amendment-set.md b/docs/amendments/v0.8-amendment-set.md new file mode 100644 index 0000000..82d9574 --- /dev/null +++ b/docs/amendments/v0.8-amendment-set.md @@ -0,0 +1,288 @@ +# Security layer model — v0.8 amendment set + +**Repository:** gate-house (author) +**Publisher:** net-kingdom +**Project family:** NetKingdom security layer +**Status:** draft — normative text proposed, not yet cut +**Version:** 0.1 +**Date:** 2026-09-06 +**Workplan:** `GH-WP-0003` +**Base:** `net-kingdom/canon/standards/security-layer-model_v0.7.md` (accepted) + +## What this document is + +The exact normative text for the amendments `GH-WP-0003` collects, section by +section, against accepted v0.7. It is the reviewable unit: each amendment can be +argued on its own wording here before any of them touch a cut document. + +v0.7 is **not** patched in place. Nothing in this file is in force. Each amendment +already governs its implementers through the decision record or contract named as its +authority — this document moves them into the statute, it does not decide them again. + +Assembly and circulation are `GH-WP-0003-T06`. + +| # | Section | Authority | Task | +| --- | --- | --- | --- | +| A1 | §9.7.3 | `GH-DEC-2026-003`, `docs/contracts/approval-consumption.md` | T01 | +| A2 | §11 | `docs/contracts/approval-emission-detection.md` | T02 | +| A3 | §13, §13.1 | `GH-DEC-2026-006` | T03 | +| A4 | §9.5 | `GH-DEC-2026-007` | T04 | +| A5 | §6.4, §8 | `GH-DEC-2026-005` | T05 | +| A6 | §17 | `GH-DEC-2026-004` | T07 | + +--- + +## A1 — §9.7.3, consume ordering (T01) + +**Defect.** v0.7 item 3 reads *"the decision precedes the action and the action +precedes consumption"*. That clause is a protocol, and it is the wrong one. It was +written to support a forensic claim, not to specify an order, but implementers read +it as the order — `APPROVAL-WP-0001-T05` and `FLEX-WP-0017-T05` were both blocked on +it. + +**Why the stated order is unsafe.** If the PEP acts and then consumes, two racing +PEPs can both observe `valid_now`, both receive ALLOW, and both act. The CAS then +prevents only the second *record*, not the second *side effect*. Single consumption +becomes theatre — the property the mutation exists to provide is exactly the one the +ordering destroys. + +**Replace item 3 with:** + +> 3. **Consumption is a state change, never an inference.** An approval is consumed +> by a mutation in `approval-engine` (§9.4). It MUST NOT be inferred from the +> existence of a decision record: a decision record proves an intent to act, not +> an act. +> +> **The PEP MUST obtain a successful consume before the protected side effect.** +> Holding a claim with `valid_now: true`, or an ALLOW rendered against that claim, +> is not authority to act; the consume is. In-flight duplicate ALLOWs are expected +> and the CAS serializes use — a later `CheckRequest` sees `valid_now: false` and +> cannot mint a new ALLOW against the same object. +> +> v0.7 stated the opposite order. Acting first leaves the CAS able to prevent only +> the second *record*, never the second *side effect*, which makes single +> consumption theatre. This is a protocol correction and not a retraction of the +> forensic claim: consumption is still never inferred from a decision. +> +> An approval authorizes one **attempt**, not one success. There is no unconsume +> and no reserve/release; a consumed approval spent on a failed action is spent. +> Reversibility would reopen replay, which is the failure the mutation exists to +> close. Settled in `GH-DEC-2026-003`; the protocol is +> `gate-house/docs/contracts/approval-consumption.md`. + +**Item 4 stays as written.** Its three failure modes now have owners rather than only +names, in the same contract; the statute continues to name them and to point at it. + +--- + +## A2 — §11, the emission-guarantee declaration check (T02) + +**Why.** `GH-IN-0001` was found by argument, not by a check: `audit-core` noticed that +§9.4 rested on a completeness property no archive can deliver. Nothing in v0.7 stops +the next engine catalogued as an evidence source from reintroducing the same gap +silently, because the obligation §9.6 creates is not on the conformance list. + +**Add to §11's "Mechanically checkable" list:** + +> - every repository catalogued in §4 as a source of evidence declares its **emission +> guarantee** in its machine-readable layer declaration: for a **load-bearing** +> source, a local transactional outbox (§9.4) plus a detection surface — heartbeat +> or reconciliation, per §9.6 — and its declared cadence; for an **attributive** +> source, the trade it makes and an explicit statement that completeness is not +> claimed. + +**Add after the list:** + +> A source that declares nothing is not conforming, and neither is one that declares +> load-bearing emission with rate monitoring alone where its event class is rare +> (§9.6). The declaration is what makes §9.6 checkable rather than reviewable; without +> it the section states an obligation whose satisfaction cannot be observed, which is +> the §9.1 defect this standard has now corrected four times. +> +> Drafted in `gate-house/docs/contracts/approval-emission-detection.md`, which +> `approval-engine`'s `cadence.yaml` implements as the reference instance. Raised by +> `audit-core` as the general form of `GH-IN-0001`, so that the finding that produced +> `GH-WP-0002` cannot recur unnoticed. + +--- + +## A3 — §13 and §13.1, register disposition (T03) + +Settled by `GH-DEC-2026-006`. The tables **stay in v0.8** and the four outstanding +stance maps are transcribed into §13.1. The migration to `maturity-engine` is +conditioned on a published export and is therefore a v0.9-or-later change, not this +one. + +**Add to §13.1, after the table:** + +> This register moves to `maturity-engine` when — and not before — that engine +> publishes a committed, versioned export of §13 and §13.1 that is readable without a +> live query, generated rather than hand-edited, and regenerable so drift between the +> export and the engine's computed state is detectable. A standard of record must stay +> legible in git, at a version, to a reader with no cluster access, including one +> auditing the estate precisely because they do not trust its running systems. A +> pointer to a live engine is an instruction to run software, not a register. +> +> `maturity-engine` already holds both registers as queryable data (`MAT-WP-0001`); +> what remains is publication, which is the migration's precondition rather than its +> follow-up. Settled in `GH-DEC-2026-006`. + +**§13.1 rows to transcribe at the cut** — carried here so the cut is mechanical: + +| Consumer | Stance map | Shape | +| --- | --- | --- | +| `ops-warden` | `ops-warden/pep-stance.yaml` | total per zone; `fail_open` for `z0`–`z2` and unknown, sanctioned by §9.3 and recorded per §6.4 obligation 1 limb two; test asserts published map equals shipped default | +| `user-engine` | `user-engine/pep-stance.yaml` | total per zone; `fail_closed` for `z0`–`z3`, unknown, and not-applicable; test asserts published map equals `user_engine.pep_stance` | +| `tenant-engine` | `tenant-engine/pep-stance.yaml` | total; `fail_closed` for unset, unreachable, non-allow, unknown; test asserts file equals shipped behaviour | +| `ops-mason` | — | **unpublished**; PEP-shaped under §6.4 (opening a route). Recorded as a gap, not a stance | + +Three of four are total and fail-closed. The `ops-mason` row is the finding §6.4's +closing paragraph anticipated, and it is more useful in the register than absent from +it. + +--- + +## A4 — §9.5, the posture/maturity boundary (T04) + +Settled by `GH-DEC-2026-007`, adopting `kings-guard`'s `KG-DEC-2026-002` with one +added clause. + +**Append to §9.5, before the approvals/maturity closing paragraph:** + +> **The boundary with posture is recomputability, not volatility.** Given the same +> criteria and the same evidence, recompute. If you MUST get the same answer, it is +> maturity and it belongs in an engine. If you CANNOT promise the same answer, it is +> posture and it belongs in Staff. +> +> This is not a new rule — it is the determinism clause above, pointed at the one +> boundary where it had not been pointed. This section already states the maturity +> half: a criterion that cannot be evaluated by rule is not yet a criterion. The +> posture half is its mirror and completes the pair: **a judgment that CAN be +> evaluated by rule is not posture — it is a criterion sitting in the wrong +> repository.** Together they partition rather than describe, which a "fast-moving +> versus slow-moving" line cannot: volatility is an observation about how a value has +> behaved, and every case it does not obviously cover becomes an argument at exactly +> the boundary §6 exists to keep out of argument. +> +> **A criterion MUST bottom out in evidence about the subject, not in another party's +> conclusion about the subject.** A recorded judgment may be evidence *that the +> judgment was made* — a fact with an issuer and a timestamp. It MUST NOT be evidence +> *that the thing judged is so*. Without this, the test is satisfiable by the +> inference it exists to exclude: *"level 2 iff the reviewer marked the control +> adequate"* recomputes identically every time and has placed an opinion inside an +> engine wearing a rule's clothes. For human-attested controls, grade on the +> attestation event's existence, freshness, and issuer — never on its verdict. +> +> Three consequences follow. **The migration direction is permanent**: anything called +> posture that proves recomputable becomes a criterion in `maturity-engine`; anything +> in `maturity-engine` that needs judgment is not yet a criterion and returns to +> Staff. **Two authorities cannot grade the same subject property**, because a +> property is either recomputable or it is not, and that does not depend on which +> repository claims it. **Capability readiness MUST NOT be an input to posture** — +> readiness is deterministic and posture is not, so feeding one into the other would +> make posture partly recomputable and blur the boundary from the Staff side. +> +> **A limit, stated rather than implied.** *"The same evidence"* is not yet well +> defined in this estate. Until §17's request-claim and gap-record schemas exist, two +> parties can disagree about whether they hold the same evidence, and recomputability +> is a thought experiment rather than a check. This makes §17 load-bearing for this +> rule. A boundary that is correct but not yet mechanically checkable is better than +> one that is checkable and wrong; a reader is entitled to know which they are +> holding. +> +> Raised by `kings-guard` against the volatility line this repository had proposed, +> and against its own convenience — the readiness constraint is one it volunteered. +> Settled in `GH-DEC-2026-007`. + +--- + +## A5 — §6.4 and §8, validation by owning layer (T05) + +**Why it belongs in the statute.** `GH-DEC-2026-005` settled it on the approval path, +but the property is general: it is a fact about the layer model, not about approvals, +and it currently lives only in a decision record and a contract. The next consumer to +join two artifacts will re-derive it or get it wrong. + +**Add as §6.4 obligation 5:** + +> 5. **Validation by owning layer.** Where a PEP's decision to act rests on more than +> one artifact, each artifact MUST be validated against the layer that owns its +> data, and a PIP MUST NOT republish the PDP's decision. A PEP MUST NOT accept the +> approval fact from the decision artifact, nor the decision from the approval +> artifact. +> +> A composed object bundling both is not forbidden as an artifact, but it is +> post-decision by construction: it cannot be served from a pre-decision call, and +> it needs a named issuer and lifecycle owner before anyone may rely on it. +> +> The live instance is the `GH-DEC-2026-003` consumption path: the approval-claim +> carries the approval fact (binding digest, validity window, consumption state, +> freshness, issuer) and the `DecisionEnvelope` carries the decision (exact +> `CheckRequest` match, policy package and version pin). Two digests may cover the +> same proposed action without being compared to each other; they answer different +> questions at different layers, and collapsing them is a layer violation in the +> shape of a refactor. +> +> **A consumer of a summary predicate trusts the issuer's evaluation of everything +> folded into it.** Where the split reduces what a PEP verifies independently — as +> `valid_now` does for an approver threshold the claim deliberately does not expose +> — the compensating property is reconstructability at the issuer under §9.6, not a +> second check at the consumer. That is detection, not prevention, and it belongs +> in the same register as §9.6's other residual. +> +> Raised by `approval-engine`, and by `access-engine` against its own proposed +> artifact. Settled in `GH-DEC-2026-005`. + +**Add to §8's demarcations:** + +> **Validating a fact** is not **re-issuing it.** A repository that checks an artifact +> against its issuer is consuming; a repository that serves another layer's conclusion +> as its own output is deciding early (§6.1), whatever the field is named. + +--- + +## A6 — §17, ownership is now assigned (T07) + +**Defect.** §17 closes with *"Ownership is proposed, not assigned… Neither has +assented."* That was true at the v0.7 cut and is now false. A reader of the accepted +statute is told the estate has not decided something it has. + +**Replace that closing paragraph with:** + +> **Ownership of the emission-cadence declaration is assigned.** `info-tech-canon` +> owns the versioned, ecosystem-wide `EmissionCadenceDeclaration` semantic contract — +> generic forms, fields, vocabulary, validation semantics, compatibility, and +> evolution. `net-kingdom` imports it and owns the NetKingdom security profile: which +> evidence classes MUST or SHOULD declare cadence, the prohibition on rate monitoring +> for rare load-bearing classes, and the heartbeat-plus-reconciliation obligations +> that satisfy §9.6. Each source repository owns its declaration instance and its +> emission behaviour; `kings-guard` owns stream evaluation and silence findings, not +> the schema. +> +> The split was made by artifact so that each has one owner: joint ownership would +> leave version authority ambiguous, and giving the whole artifact to either +> repository would conflate a reusable evidence contract with the security +> obligations of one estate. Settled in `GH-DEC-2026-004`; both repositories accepted +> in their own voice (`ITC-WP-0018`, publishing `ITC-EMISSION-CADENCE 0.1` in canon +> `0.7.0`; `NK-WP-0035`, publishing `emission-cadence-security-profile_v0.1.md`). The +> `kings-guard` draft is frozen as assimilation provenance. +> +> **Ownership of the remaining three artifacts is still proposed.** The request-claim +> and gap-record schemas sit between `info-tech-canon` and `net-kingdom` on the same +> unsettled line; the decision-record schema is `access-engine`'s, per above. §2 keeps +> ownership in the owning repository's `INTENT.md`. + +--- + +## Not in this set + +Recorded so the omissions are deliberate rather than forgotten. + +- **§12's fourth step remains unstaffed.** Observation in production is still not + live; `kings-guard`'s `qonto-assistant` pilot is fixture-only. That is a status, not + an amendment, and §12 already says so. +- **§16's open questions are not re-cut here.** Several have been answered by decision + records since v0.7. Reconciling §16 against the decision log is `T06` work at + assembly, not a separate normative amendment. +- **No §4 catalog change.** None of these amendments moves a capability between + repositories. diff --git a/workplans/GH-WP-0003-statute-v08-amendment-set.md b/workplans/GH-WP-0003-statute-v08-amendment-set.md index 8719e94..8156af1 100644 --- a/workplans/GH-WP-0003-statute-v08-amendment-set.md +++ b/workplans/GH-WP-0003-statute-v08-amendment-set.md @@ -18,6 +18,11 @@ state_hub_workstream_id: "a331dc88-c9bc-5d2a-9ff1-2aa7e837c3bb" Land the queued amendments to security-layer-model as v0.8: the §9.7.3 consume-ordering protocol clarification, the §11 emission-guarantee declaration check, the §13/§13.1 register disposition against maturity-engine, the §9.5 posture/maturity recomputability boundary, and the GH-DEC-2026-005 split-validation doctrine. Each is currently doctrine held in a gate-house contract or decision rather than in the accepted statute. +**Normative text for A1–A6 is drafted at +`docs/amendments/v0.8-amendment-set.md`.** That file is the reviewable unit: each +amendment carries its own wording, defect statement, and authority, so it can be +argued before anything touches a cut document. T06 assembles from it. + ## Why now `security-layer-model_v0.7.md` is accepted and must not be patched in place. Since