No change in the evidence: feedback/ holds only the two 2026-08-15
resource-control reports, incoming/ only its README, and no inbox message is an
emission-cadence declaration. The sole declaration in the repository is still
the worked example, which the standard states is not source-owned.
What this repository owes the gate was re-tested rather than assumed.
emission-review validates an arbitrary source-owned declaration and reports
operational_truth_assessed false, so a submission cannot be read as observed
behaviour, and export-emission-contract produces a bundle whose manifest carries
the gate in words at digest 972c0b6701d1693f, which a source owner can pin to
today.
The blocker is not readiness but that no external source owner has been asked.
The contract came from the King's Guard taxonomy with evidence classes owned by
NetKingdom, which makes netkingdom the obvious first source owner and a second
one that must be independent of it. Soliciting them is an outward action this
workplan does not authorize, so T06 stays waiting on that decision.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3588@bnt-lap001
Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
The role set — Principal, effective actor, Delegator, tool or agent, policy
ceiling, execution context, audit identity — now applies wherever a subject's
access is exercised through another party, rather than to non-human subjects
only.
The gap this closes is not about agents. A support operator impersonating a
customer involves no non-human subject anywhere in the path, yet without the
decomposition that operator's audit identity and policy ceiling collapse into
the customer's, which is the outcome CARING's exposure analysis exists to
prevent. CARING already names customer impersonation as an exposure mode and
ImpersonationBlocked as a control; the vocabulary for analysing it was gated to
subjects the case does not involve. Section 33 was already subject-agnostic, so
the canon applied the execution paths to any subject while restricting the roles
along those paths to non-human ones — an artifact of the section heading, not a
considered position.
Accepted narrowly. Section 32.1 stays agent-stated, with a note on reading the
capability ceiling for a human effective actor. No role is removed, renamed or
added, and section 33 is untouched. Option C, a twelfth dimension, is rejected as
duplicating sections 32 and 33 while touching a dimension set the Kubernetes RBAC
benchmark depends on.
Canon version moves to 0.4.0-RC2-itc2; source version stays 0.4.0-RC2, since
this revises the InfoTechCanon-aligned standard and claims nothing about
upstream CARING. The change is additive: an implementation that applied the set
only to non-human subjects stays conformant for those subjects.
Review record in history/; the SecurityCanon boundary file and placement record
are updated to show R-2 resolved.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3588@bnt-lap001
Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3588@bnt-lap001
Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
Updated by fix-consistency on 2026-09-20:
- update .custodian-brief.md for info-tech-canon
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3588@bnt-lap001
Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
interface-canon corrected its Interface and Endpoint pins at 20d7bfc2. Both were
pinned twice, to ITC-LAND and ITC-NET, because ITC-LAND section 13.2 lists them
in a seed-concept block while the Network Model defines them. Landscape section
13.2 now says in this repository that Interface, Endpoint and API are pointers
there and that the Network Model owns the first two, so the next reader does not
repeat it.
That is the fourth time in one day a list of concept names was read as a
definition, after CARING's Scope ladder, CARING's Environment values, and the
Landscape seeds that hid SoftwareSystem and SoftwareComponent. The closure
section names the pattern.
Both boundaries now resolve completely, security-canon 11 of 11 and
interface-canon 23 of 23, the registered copy is refreshed to the corrected
revision, and validation carries no drift warnings. The CLI test is rebuilt from
a deliberately broken copy so that a partner fixing its own pins can no longer
break this repository's suite.
make check passes with 59 tests, clean validation and no warnings.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3588@bnt-lap001
Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3588@bnt-lap001
Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
Updated by fix-consistency on 2026-09-20:
- update .custodian-brief.md for info-tech-canon
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3588@bnt-lap001
Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
import-review takes any partner manifest and returns, per concept, whether the
name resolves in the ownership index and to which artifact, and per entry
whether the pinned SHA-256 matches the blob at the declared source commit. Both
run in one pass so neither can be recorded without the other, which is the
failure this workplan exists to prevent. It exits non-zero on a finding, reads
JSON or YAML, needs no partner checkout, and carries its own limit: resolution
proves a name exists and names one owner, nothing more.
Accepted manifests are registered under infospace/interfaces/manifests/ as
provenance-preserving copies owned by the partner, with the partner revision and
retrieval date recorded. Editing a copy to make a check pass is forbidden in the
file itself. Validation re-resolves them and reports drift as
federation_import_drift, a warning naming the partner rather than an error,
because a stale partner pin is not this repository's file to fix.
The review kit gains an extension-boundary-review template requiring hash count,
resolution count and conflict count as three separate lines, and an operating
rule saying one is never evidence of another. Both boundary files carry the
standing-check result.
Verified live: security-canon resolves 11 of 11, interface-canon 23 of 25 with
the two known Interface and Endpoint pins. make check passes with 58 tests,
clean validation and those two warnings.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3588@bnt-lap001
Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
Federation partners pin an artifact path, a blob hash and a list of concept
names. Every review so far verified the hash and recorded the match as evidence.
A hash proves the reviewed file is the pinned file; it says nothing about whether
the concept named in the manifest exists in it. Nobody ran the second check until
INFO-WP-0027-T04, which found nine failures across the two accepted boundaries,
none of them a contested concept and all of them a citation naming the wrong
artifact or a name this canon never used.
The workplan adds a reusable import-review command in the shape emission-review
already uses, registers accepted manifests so drift is caught when this
repository changes rather than when a partner happens to look, generalises the
re-verification section into the review kit so an acceptance cannot again record
matching hashes as evidence of correct citation, and closes the two open pins
InterfaceCanon still owns.
Drift against a registered manifest is a warning, not an error: a stale partner
pin is not this repository's file to fix and must not fail its build.
Status is proposed: drafted from the INFO-WP-0027 findings, not yet reviewed by
the owner.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3588@bnt-lap001
Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3588@bnt-lap001
Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
Updated by fix-consistency on 2026-09-20:
- update .custodian-brief.md for info-tech-canon
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3588@bnt-lap001
Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
R-3 is resolved by disambiguation without a rename. CARING section 10.7 now says
its Authority exposure mode names a demanding party rather than a right, links to
ITC-ORG section 10.17, and notes that such an Authority holds no organizational
authority over the system it compels. ITC-ORG carries the reciprocal sentence and
records that SecurityCanon's AuthMode qualifies the exercise of the right rather
than redefining it.
The seventeen concepts no artifact declared are now declared: eleven to the
Organization Model, four to CARING and two to the Capability Model. Capacity in
the Organization Model and Capacity behaviour in the Capability Model are two
concepts, not one, and neither moves. Two of CARING's four turned out not to be
new concepts at all but the prose spellings of CaringCapabilityProfile and
CaringDerivedCapability; both spellings are declared to the same owner so the
name a reader meets resolves. Effective Access and Declared Access were
genuinely undeclared.
Three boundary reviews are added for organization, caring and capability,
bringing the count to fourteen. The concept_defined_without_owner warning is at
zero, and the test that asserted it fires now proves it on a modified corpus
instead of on the live one.
make check passes with 54 tests, clean validation, no warnings, no stale assets.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3588@bnt-lap001
Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3588@bnt-lap001
Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
Updated by fix-consistency on 2026-09-20:
- update .custodian-brief.md for info-tech-canon
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3588@bnt-lap001
Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
Neither boundary has an ownership conflict now that declarations cover the
corpus, so the central claim of both acceptances holds. Name resolution is a
different matter, and it had never been checked: both original reviews verified
their import manifests by file hash, every hash matched, and that was recorded
as evidence. A hash proves the reviewed file is the pinned file; it says nothing
about whether the concept named in the manifest exists in it.
SecurityCanon: five of twelve imports named concepts their pinned artifact does
not define, corrected on that side to eleven imports. InterfaceCanon: twenty-one
of twenty-five resolve exactly, and two of the four failures were this
repository's omission — SoftwareSystem and SoftwareComponent are Landscape seed
concepts that extraction cannot read and are now declared, making those pins
correct. Interface and Endpoint resolve to the Network Model, which the accepted
clarifications already treat as contextual rather than exact aliases; those pins
are InterfaceCanon's to correct.
Both boundary files carry the re-verification and its method limit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3588@bnt-lap001
Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
validation-coverage gains a concept_declaration block: declared, defined in
prose, undeclared, ratio, silent artifacts, and the extraction limit stated in
words. The ratio sits slightly above one because seed-concept lists and YAML
payload concepts are declared but not extractable, and saying so in the report
is better than a number that looks complete.
Two checks carry different weights. concept_declaration_missing is an error: an
artifact that defines concepts and declares none, with the kernel map exempt by
name because it assigns concepts rather than defining them. Zero today, so a new
artifact added without declarations fails. concept_defined_without_owner is a
warning over concepts no artifact declares; a name another artifact owns is an
import rather than a gap, which keeps the warning from firing 57 times and
training reviewers to ignore it.
Three warnings today and each is real: the Organization Model defines eleven
concepts nobody owns, CARING four including Effective Access and Declared
Access, and the Capability Model two. They are carried as T07 rather than
declared in passing, because declaring without a boundary review is the mistake
this workplan exists to fix.
make check passes with 53 tests, clean validation and three warnings.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3588@bnt-lap001
Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3588@bnt-lap001
Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
Updated by fix-consistency on 2026-09-20:
- update .custodian-brief.md for info-tech-canon
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3588@bnt-lap001
Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
Twelve of the thirteen artifacts that declared nothing now declare what they
define, together with the map-assigned concepts the Organization Model was
missing and the Landscape seed concepts the extractor cannot see because they
are listed rather than defined in prose. The ownership index grows from 164
entries to 750, undeclared prose definitions fall from 637 to 57, and there are
no ownership conflicts. The 57 that remain are overlaps this round assigned to
another owner: imports, each recorded in a boundary review.
The kernel map declares nothing, deliberately, because it assigns concepts to
owners rather than defining them. It is now the only silent artifact and the
suite asserts that, so an artifact added without declarations fails.
itc-org:Authority is declared, with Actor, Ownership, Membership, Role,
Responsibility and Accountability, which SecurityCanon and the identity model
already treat as organization-owned. The regression test that previously
asserted the blind spot now asserts that the kernel map's assignment and the
declaration agree.
Profile is deliberately left undeclared. The kernel map assigns it to Core, the
identity model owns it under accepted CUST-ADR-006, and Observability defines a
runtime performance profile. Three senses need a decision, not a declaration, so
it is recorded as open rather than forced.
Eleven boundary reviews are added beside the artifacts they describe, in the
shape the identity model has used since INFO-WP-0021. The largest finding is
that Core and the Information Space model restate eight provenance concepts in
nearly identical words; Core owns them and Information Space imports. Label,
Drift, Summary and Attribute are resolved by disambiguation rather than
transfer.
make check passes with 50 tests, clean validation, no stale generated assets.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3588@bnt-lap001
Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3588@bnt-lap001
Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
Updated by fix-consistency on 2026-09-20:
- update .custodian-brief.md for info-tech-canon
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3588@bnt-lap001
Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
Adds maintenance.concept_candidates() and the concept-coverage CLI command,
which measure concepts an artifact defines in prose against the concepts it
declares. Extraction covers the bold form, the numbered-heading form that hid
itc-org:Authority, and the concept-table form the kernel map uses; preserved
source under assimilation, seeds and incoming is excluded. Candidates are review
input, never ownership.
Baseline over 31 live artifacts: 113 concepts declared against 690 defined,
leaving 637 defined but undeclared, about 16 percent coverage. The workplan's
519 counted the bold form alone.
Two corrections to the workplan's framing, applied there. Thirteen artifacts
declare nothing rather than twelve: kernel/itc-core defines 57 concepts across
two forms and declares none, and it is the artifact every other artifact imports
from, so it goes first in T02. The gap also reaches further than obscure terms —
Actor is undeclared in the organization model although SecurityCanon imports it
from there by name against a pinned hash.
Three tests cover the extractor, one asserting that Authority appears in the
organization model's undeclared list, so the blind spot that produced finding
F-1 now has a regression test. make check passes with 49 tests.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3588@bnt-lap001
Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
The ownership index is built from artifact titles and owned_concepts frontmatter
only, so the conflict check cannot see a concept that is defined in prose,
assigned an owner by the kernel map and referenced elsewhere by qualified id.
Measured at 209bb5a: 164 index entries against twelve live models and standards
that declare nothing, and 519 bold-form definitions across fifteen live
artifacts that appear in no declaration.
The SecurityCanon boundary review recorded a clean conflict result that could
not have seen itc-org:Authority for exactly this reason; the gap was caught by
hand in SECURITY-WP-0001-T03. The workplan establishes the true denominator,
declares concepts for the twelve silent artifacts, reports coverage as a moving
number with a recorded enforcement level, re-verifies both accepted extension
boundaries against the enlarged index, and resolves residual R-3 as its first
real use. Residual R-2 is explicitly excluded.
Status is proposed: drafted against verified repository state but not yet
reviewed by the owner.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3588@bnt-lap001
Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3588@bnt-lap001
Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3588@bnt-lap001
Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
The SecurityCanon boundary review recorded a residual: CARING and ITC-ACCESS
hold two definitions of Scope, with ITC-ACCESS named owner. Reading the corpus
corrects both halves. ITC-IDENT section 2.10 owns Scope as the general boundary
within which identifiers, meanings, relationships, accounts, policies or
lifecycle states are valid, and ITC-ACCESS section 11.8 ResourceScope already
declares itself a refinement of that general identity Scope rather than a
competing definition.
The second use the residual was reaching for is CARING section 21, which
presented a dimension named Scope with a ladder from Ecosystem to Field without
saying what the dimension ranges over. It now states that it ranges over
ITC-IDENT Scope instances, that the ladder is the canonical value set rather
than a second definition, and that ResourceScope refines the same concept for
resource boundaries.
No concept is renamed, moved or removed and no ladder value changes, so the
corpus is unchanged in shape; make check passes with 46 tests, clean validation
and a passing small-saas profile. The correction is carried back to the
SecurityCanon placement record and imports.json, where Scope now imports from
the identity model.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3588@bnt-lap001
Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
SecurityCanon publishes an architecture-layer vocabulary for authority
relationships, the Mode of Authority, and references shared InfoTechCanon
concepts. This records the InfoTechCanon-side acceptance of that boundary and
adds reciprocal navigation from the federation interface README.
The accepted dispositions keep the layers apart. Mode of Authority describes the
relationship in which authority is exercised; CARING analyses how an
access-control implementation is composed. Auth Mode is orthogonal to access
operation and to CARING's Canonical Role and Plane, so the Operator role and the
OPERATE mode stay distinct concepts and neither is renamed. SecurityCanon does
not reuse Actor or Subject, which ITC-ACCESS owns and binds as "Subject is the
access-control view of an actor"; it renamed its on-behalf-of dimension to
AuthorityContext instead, so no change is required here.
Verified at security-canon b1fa25eb: all five pinned manifest hashes match Git
blobs at this commit and the sources are unchanged in the review checkout, and
none of the seven concepts SecurityCanon declares appears in any InfoTechCanon
owned_concepts declaration, so the boundary introduces no ownership conflict.
No concept is transferred and nothing is removed, so the corpus is unchanged.
Generated indexes and the repository tree are refreshed for the added file;
make check passes with 46 tests, clean validation and a passing small-saas
profile. This is an agent review, not human sign-off, and it records no consumer
adoption or conformance claim.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AUkN13CAqtXWPXuEiEtmJj
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 36656@bnt-lap001
Assistant-Session: 66d6eece-d245-43ca-85e8-68a1b5970a67
Set flavor on open workplans from origin/prose/status. Copy existing
depends_on aliases only. Do not promote residuals.
Assistant: grok
Assistant-Session: 01a09dc1-b21e-77e1-919e-fcad2f82b267
Regenerated by fix-consistency; adds the inbound layer-declaration intake.
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
The layer model is now published as
net-kingdom/canon/standards/security-layer-model_v0.1.md (proposed) and
ratified by gate-house GH-DEC-2026-001. The note previously said the
standard was not yet written.
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
Records this repository's layer in the NetKingdom IT-security layer model
(Taxonomy / Tooling / Engines / Staff) and what should change in this INTENT
as a result. Links to the review that established the model:
gate-house/history/2026-08-28-security-layer-model-and-gate-house-recut.md
The note flags pending adaptation only; the body is unchanged.
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
`ADHOC-YYYY-MM-DD` is unique per date but not per repository, so any two repos
opening an ad-hoc on the same day collide. The 2026-08-26 fleet projection
reset refused 9 records for exactly this reason.
Canon (work-record-types_v0.1, CUST-WP-0066) settled the form as
`{PREFIX}-WP-ADHOC-YYYY-MM-DD`, filename unchanged, and grandfathered existing
ids on the condition they are never *silently* re-derived. This is the explicit
migration that clause allows for.
The hub id is derived from the record id, so a changed id is a different
record: stale state_hub_*_id fields are dropped and fix-consistency re-derives.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
These workplans exist only in the retired local hub. Their random pre-ADR-007
identifiers are refused by C-06 as stale references, so they cannot be
registered. Deriving from the canonical record id takes no identity from
anything: central does not hold them and the old ids die with the cache.
Records central already holds were deliberately left untouched.
Refs CUST-WP-0068-T06
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
Updated by fix-consistency on 2026-08-25:
- update .custodian-brief.md for info-tech-canon
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
The remote row pointed at 127.0.0.1:18000, a reverse tunnel back to the
workstation. On railiance01 the State Hub runs in the cluster on that same
machine, so the request left the box and came back to reach a local service.
Refs CUST-WP-0067-T07
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
