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
Inbound consumer demand from FIN-WP-0007. Asks for a lineage qualifier
on CapabilityConsumption, commerce.entitlement/metering structure, and
dropping cost as an intelligence quality. No model change.
Finish ITC-WP-0013 (AttributeValueType under ITC-DATA) and ITC-WP-0014
T02/T03/T05/T06/T07. Capability contract schemas, live-catalog review
CLI, landscape/kernel-map pointers. Sit on this version.
A provision can name which other provision satisfies a catalog
dependency. Relation vocabulary is depends_on / may_use only.
Quoted sits below the invoiced/measured peer pair for propagation.
