tegwick
66dc491dc0
The standard is accepted at v0.7 on the owner's decision. §14 keeps two things apart, as ops-warden asked: boundary assent, given by four repositories at the version named in each record and undisturbed since; and revision review, where all four reviewed v0.6 and every change in v0.7 is the adopted remedy of a finding they raised. What is not claimed: nobody has reviewed v0.7 as text. Accepting a standard nobody has re-read is deliberate. The estate will learn more from using it than from another round of prose, and the v0.7 changes were requested rather than invented. Findings against the accepted text stay welcome — that is §12's normal business, not an exception. The companion moves from canon/standards to the repository root as SECURITY-COMPANION.md and becomes v0.2, so onboarding starts at the front door rather than three directories down. One copy, not two: a second copy of a fact is how the estate gets two sources for it. v0.2 closes the gap access-engine found in v0.1 — it said publish your stance map without saying where, and omitted the inventory obligation, so a repository could satisfy it faithfully and no register would learn of its stance. It also carries what v0.7 added: the corrected PEP obligations, the evidence threat decomposition with its stated residual, cadence as MUST for load-bearing sources with heartbeat for rare ones, the four agent rules and the glas-harness seam, and the Railiance axes with their unsettled mapping. It points readers at ops-warden for how to get things done. The companion says what the rules are; ops-warden stewards the paths through them. 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
31 lines
1.7 KiB
Markdown
31 lines
1.7 KiB
Markdown
# NetKingdom
|
|
|
|
NetKingdom is the canonical security architecture, integration boundary, and
|
|
bootstrap/reference implementation for NetKingdom environments. It defines
|
|
identity, tenancy, credential, workload-zone, and security-composition
|
|
contracts while leaving provider and Railiance execution in their owning
|
|
repositories.
|
|
|
|
The dynamic, self-optimizing security platform is the long-term direction in
|
|
[INTENT.md](INTENT.md), not a claim about current delivery.
|
|
|
|
## Orientation
|
|
|
|
- [SCOPE.md](SCOPE.md) — what this repo owns, current state, and when it is relevant
|
|
- **[SECURITY-COMPANION.md](SECURITY-COMPANION.md) — start here.** The working
|
|
form of the security layer model: what to declare, what binds you, what you may
|
|
never claim about evidence, and the two things the estate cannot do yet
|
|
- [Security layer model](canon/standards/security-layer-model_v0.7.md) — the
|
|
statute the companion serves (accepted 2026-08-29): 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)
|
|
— deterministic, plan-only capability and trust composition
|
|
- [Posture feedback](canon/standards/posture-feedback_v0.1.md) — deterministic,
|
|
proposal-only posture and evidence remediation findings
|
|
|
|
## Security Infrastructure Documents
|
|
|
|
- [secrets-engine security infrastructure boundary](docs/secrets-engine-security-infrastructure-boundary.md)
|
|
defines how secrets-engine participates in the NetKingdom security
|
|
infrastructure and how it interacts with OpenBao, flex-auth, user-engine,
|
|
ops-warden, ops-bridge, info-tech-canon, State Hub, and agents.
|