Commit graph

13 commits

Author SHA1 Message Date
745dffb8ac Security Layer Model v0.6 — type the engines, name the gate, hold actuation at zero
From the independent assessment of 2026-08-29, which found the model sound as a
layering constitution and incomplete as a self-healing one: cognition,
authority, and execution are specified, but the two verbs that close a healing
loop — observe in production, actuate through a deterministic surface — are
pending, and one is unstaffed.

Section numbers below §14 are unchanged; the estate cites them.

- §3.3 types the Engine layer: PDP, PIP, Evidence, Lifecycle, with a role column
  in §4. Collapsing them hid different failure modes — a PIP outage is input
  degradation, a PDP outage is consumer residue, an evidence-plane outage must
  not block the operation it records. A new engine is a PIP unless amended.
- §6.4 names the enforcement point. The standard was precise about the decision
  and silent about the gate, so enforcement lived in Staff runbooks. Four
  obligations: no side effect without a decision record, no local recaching of
  the verdict, a declared unreachable-engine stance, reconstructability.
- §9.2 replaced. Containment was marked pending against kings-guard, the right
  mark on the wrong repository: reduce, step-up, and isolate are
  authority-changing operations, so they are rendered by an Engine and enforced
  by a PEP. Actuation is an unowned Engine concept held at zero. Staff proposes
  containment and never performs it.
- §3.4 separates human and agent principals inside Staff — same permissions,
  different blast radius. No standing credential, conduit or engine API only,
  agent memory is not a state plane, every action reconstructable as the
  caller's.
- §9.7 puts time into the model: explicit lifetimes, revocation visibility
  deadlines, consumption as a state change never inferred from a decision
  record, and the three race modes named. §9.8 states what holds under
  partition.
- §17 requires the Taxonomy artifacts — claim, decision-record, gap-record, and
  emission-cadence schemas — without which §6.2 and §11 are reviewable but not
  compileable. Ownership proposed, not assigned.
- §18 composes the sibling standards, which had been cited in frontmatter and
  nowhere in the rules.
- §5 sunsets the uncatalogued-infrastructure carve-out. §5.3 declines a proposed
  fourth "operator of third-party Tooling" shape: it would convert a tracked gap
  into a permanent allowance, which is the relabelling failure this standard
  exists to prevent.
- §10 gains the six artifacts a layer change must carry, written from the
  zone-engine case, including a permission freeze during the cut.
- §2 lifts the observation rule so it cannot be lost in a summary. §13 separates
  its three normative rules from the table, now a snapshot due to move into
  maturity-engine. §16 decides the approval custody question: no. §19 records
  the fitness verdict.

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 03:32:58 +02:00
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
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
90cc64f728 Security Layer Model v0.3 — assign approvals and maturity
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
2026-08-28 22:34:58 +02:00
27a31f3f8f Security Layer Model v0.2 — accepted
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
2026-08-28 22:00:31 +02:00
1c3a9b46e3 Add NetKingdom Security Layer Model v0.1 (proposed)
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
2026-08-28 20:59:00 +02:00
cfc9e7d0cb feat(posture): add deterministic feedback proposals
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a02929-244b-7391-b933-c04010e8eedb
2026-08-23 13:16:34 +02:00
d96aab2321 feat(orchestration): compose security scenarios
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a02929-244b-7391-b933-c04010e8eedb
2026-08-23 12:40:52 +02:00
cd8a633ad9 Remove STATUS.md; SCOPE.md is the canonical orientation doc
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 3s
STATUS.md duplicated SCOPE.md intent. Drop the file and point README
orientation at SCOPE.md only.
2026-07-08 13:19:06 +02:00
802d7f258c Link STATUS.md from README orientation section
All checks were successful
CI Smoke / host-smoke (push) Successful in 1s
CI Smoke / container-smoke (push) Successful in 5s
Add Status & Orientation section pointing to STATUS.md and SCOPE.md.
2026-07-08 13:07:03 +02:00
9a7d10f840 Repo hygiene: fill stack-and-commands, normalize workplan statuses
- 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>
2026-07-02 00:21:49 +02:00
004a8d6e6b Add CLAUDE.md, wiki protoplans, and NK-WP-0001 workplan
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>
2026-02-28 17:21:51 +01:00
Coulomb Social
a852627f0c Initial commit 2026-02-28 09:41:41 +00:00