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
v0.2 recorded the approval object as the one open architectural hole, and
carried a latent instance of its own §9.1 rule: gate-house was catalogued as
owning conformance review with no engine to act through. Two engines were
seeded to close both.
- §9.4: the approval object goes to approval-engine — not Staff (§3.4 forbids
the runtime state), not access-engine (an evaluator owning what it evaluates
is self-dealing), not audit-core (append-only is the opposite property).
access-engine consumes approvals as input claims under §6.2; audit-core takes
the tamper-evident evidence. Operative state and evidence record are separate
artifacts with separate owners.
- §9.5: graded progression goes to maturity-engine. gate-house judges and
proposes; maturity-engine computes and remembers. Carries the guardrail that
a level may never gate a decision directly — under §6.1 that would be a
second decision point by the graded back door.
- §4 catalog gained both engines; §13 register updated.
Status proposed: the new engines are seeded by owner direction with no other
side to assent yet, and the approval evidence half needs audit-core's assent.
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
All three repositories whose boundaries moved assented, each with a decision
record (flex-auth FLEX-DEC-2026-001, kings-guard KG-DEC-2026-001, ops-warden
ADR-0010), and each returned a finding. v0.2 carries the results and is
accepted; v0.1 is marked superseded and retained because the twelve estate
INTENT review notes cite it.
- §5 restructured into three sanctioned shapes: read-only diagnostics, conduit
(ops-warden's question, ruled), and declared engine gap (ops-warden's
amendment, accepted). v0.1 offered only the first, which is narrower than the
estate as it stands — a rule with no lane for a real sanctioned case gets
satisfied by relabelling rather than by closing the gap.
- §6.2 added: doctrine must reach the decision as an input claim or a versioned
policy rule. This is §6.1 applied to gate-house on the same terms it applies
to engines, drawn back by flex-auth.
- §9 added: the catalog may not assign a capability the rules forbid
discharging. Containment marked pending an engine surface; degraded-mode
fallback ruled into access-engine rather than Staff.
- §11: conformance now has three states, distinguishing a tracked gap from an
undeclared violation.
- §12 made normative, stating that an unsatisfiability finding is a success of
the conformance loop.
- §13 added: open gaps register, including the unowned approval storage and
lifecycle capability — recorded, deliberately not assigned.
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
States how the security estate is layered — Taxonomy, Tooling, Engines,
Staff — distinguished by determinism and by the artifact each layer
produces, and what each layer may own.
Carries two normative rules. §5: Staff never touches Tooling directly; it
acts only through Engine APIs — the architectural form of "no privilege
from cognition", and mechanically checkable. §6: access-engine is the only
policy decision point, generalizing to the whole estate the ruling first
drawn in zone-engine/INTENT.md §5, and barring any Staff repository from
hosting a decision point.
Also fixes the vocabulary the estate has used for more than one thing:
access lane vs access rule, doctrine vs runbook, control plane as Engine
vocabulary, and the posture asymmetry.
Owner gate-house, published by net-kingdom. Status proposed: the two
adaptations carrying the most weight — flex-auth's reframing and rename to
access-engine, and kings-guard and ops-warden releasing vocabulary — are
not yet assented by their owners.
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
- Fill .claude/rules/stack-and-commands.md (was an empty TODO template)
- Normalize workplan frontmatter statuses to canonical vocabulary
(completed/done -> finished) per ADR-001
- Repair glued frontmatter delimiter in NK-WP-0001 (superseded_by line)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Initialises the net-kingdom project structure:
- README.md: updated title and description
- CLAUDE.md: project instructions and State Hub integration config
- wiki/: three reference docs (NetKingdom overview, ChatGPT and Grok
protoplans for the SSO/MFA platform)
- workplans/NK-WP-0001-sso-mfa-platform.md: combined workplan (8 phases,
8 tasks) synthesised from the two protoplans; registered in the
Custodian State Hub (workstream 39263c4b)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
