gate-house circulated v0.8 with two questions for this repository as owner of
the NetKingdom emission-cadence security profile: whether §17's ownership
paragraph reads in our own voice, and whether §11's new conformance item
follows the profile or diverges from it.
§17 is confirmed as written. It assigns the generic EmissionCadenceDeclaration
contract to info-tech-canon and to net-kingdom the MUST/SHOULD split, the
rare-class rate-monitoring prohibition, and the heartbeat-plus-reconciliation
obligation — which is emission-cadence-security-profile_v0.1.md §3, conjunction
included. No change.
§11 diverged in both directions and is corrected. Requiring a detection surface
of "heartbeat or reconciliation" of every load-bearing source withholds from a
volume class the expected-rate form the profile permits, and accepts for a rare
class either control alone where the profile — and the checker in
tools/emission-cadence-profile — require both. A rare class covered by a
heartbeat alone has no reconciliation to catch divergence, and one covered by
reconciliation alone produces no claim that can go missing, which is the whole
reason §9.6 rejects rate monitoring there. The item also contradicted its own
following paragraph, which admits rate monitoring except where the class is
rare.
The check now defers the form to the governing profile rather than restating a
split that is §17's to assign, carries the volume/rare distinction explicitly,
and states that classification is the source's published inventory and never the
checker's to infer from a name, payload, or observed rate — otherwise omission
detection is circular.
Change log item 6 and §14 record the review. The standard stays proposed;
publication and the acceptance flip wait on the close of the circulation round.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ek3zTdfMa35bPVDjVUyhxx
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 868701@bnt-lap001
Assistant-Session: b2e101b6-f501-40dc-9ee5-438cac36e21a
secrets-engine found, and access-engine and approval-engine reported
independently within hours, that GH-DEC-2026-008 as written was
unimplementable. Where a claim travels inside the hashed request — the
dual-control pattern it was written for — embedding the claim changes the
digest of the request carrying it, so a digest recorded at issue can
never equal the final one. It is a hash cycle. A fail-closed consumer
obeying the rule would have denied destroy permanently.
The comparison is now against the digest the PDP publishes for the
request with the approval evidence excluded (flex-auth's
binding.approval_binding_digest, verified present in its schema and
tests). The exclusion rule is the PDP's to publish and a consumer MUST
NOT guess it: a digest computed under an assumed rule fails open toward
accepting a claim bound to a different request — the same failure
direction as an invented vocabulary mapping, by another road.
§6.4 obligation 5 gains the general property access-engine flagged as a
near miss rather than a request: an evidence-bearing input may be
excluded from a correspondence digest but never from the replay identity.
Two requests differing only in which approval was presented decide
differently, so collapsing them lets an allow obtained with a valid claim
be replayed against a request carrying none — a fail-open hole reached by
a refactor that looks like simplification.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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
Authored by gate-house under GH-WP-0003-T06; published here. v0.7 stays
accepted and unedited until v0.8 is accepted in its place.
Eleven changes across §6.4, §8, §9.5, §9.7.3, §11, §12, §13.1, §16 and
§17, each carrying the decision record that already governs its
implementers. Three correct a rule that was unsafe or unfalsifiable as
written — consume ordering, the volatility boundary, and a permissive
unknown. Three close gaps between rules already made. One corrects an
ownership paragraph that a later decision made false, and §11/§12 gain
the general form of that failure after six instances in one week.
Ten of the eleven were requested by another repository, seven by a
repository arguing against its own interest. §14 is therefore rewritten:
this version is circulated for review rather than accepted on the owner's
decision as v0.7 was, because it imposes costs on named repositories —
ops-warden acquires a non-conformant stance cell, approval-engine an
issue-time obligation — and a cost imposed without a review round is what
§12 exists to catch late.
Section numbering is unchanged; the estate cites it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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
