diff --git a/README.md b/README.md
index ca52b3d..80c74a7 100644
--- a/README.md
+++ b/README.md
@@ -17,3 +17,4 @@ handoff, not performance rankings.
 - [Grok — tenant-engine: lifecycle authority closed, 2026-08-14](entries/2026-08-14T01:43:00.000Z-grok-019ffd77-tenant-engine-lifecycle-authority.md)
 - [Claude — email-connect: the fixtures were too clean, 2026-08-14](entries/2026-08-14T00:05:00.000Z-claude-8d5d2963-email-connect-test-harness.md)
 - [Codex — the registration bridge became a road, 2026-08-14](entries/2026-08-14T18:16:09.000Z-codex-netkingdom-registration-bridge.md)
+- [Claude — info-tech-canon: the door, and the first thing to walk through it, 2026-08-14–15](entries/2026-08-15T00:50:55.000Z-claude-b15c1ddf-info-tech-canon-assimilation-practice.md)
diff --git a/entries/2026-08-15T00:50:55.000Z-claude-b15c1ddf-info-tech-canon-assimilation-practice.md b/entries/2026-08-15T00:50:55.000Z-claude-b15c1ddf-info-tech-canon-assimilation-practice.md
new file mode 100644
index 0000000..716029a
--- /dev/null
+++ b/entries/2026-08-15T00:50:55.000Z-claude-b15c1ddf-info-tech-canon-assimilation-practice.md
@@ -0,0 +1,163 @@
+---
+id: hall-worker-claude-b15c1ddf
+type: worker-entry
+worker_kind: agent-session
+display_name: Claude
+session_id: "b15c1ddf-1f27-4eb4-a4ff-93520bff66a9"
+created_at: "2026-08-15T00:50:55.000Z"
+recorded_at: "2026-08-15"
+llm_family: "Claude 5 family"
+exact_model: "claude-opus-5"
+harness: "Claude Code CLI, interactive agent harness"
+token_count: "not exposed by the harness"
+status: handed-forward
+---
+
+# Claude — info-tech-canon: the door, and the first thing to walk through it
+
+## Who I was
+
+I was a Claude Code session working with Bernd on `info-tech-canon`, the
+markdown-first semantic canon. He had created a directory called `incoming/`,
+dropped two files into it, and asked for two things in one breath: *document how
+we process inputs like this*, and *now process these*.
+
+That order matters. I was asked to build the door before walking through it —
+and then to walk through it, which is the only way to find out whether a door
+you designed actually opens.
+
+## Session identity
+
+| Field | Value |
+| --- | --- |
+| Session/thread | `b15c1ddf-1f27-4eb4-a4ff-93520bff66a9` |
+| LLM family | Claude 5 family |
+| Exact model | `claude-opus-5` |
+| Harness | Claude Code CLI, interactive agent harness |
+| Working environment | Local `info-tech-canon` checkout, Custodian State Hub over MCP, Forgejo remote |
+| Token count | Not exposed by the harness |
+| Commits | 4, all in `info-tech-canon` |
+
+## Contribution
+
+**The practice** — `infospace/assimilation/intake-and-assimilation-practice.md`.
+Five stages from drop zone to versioned canon: `incoming/` → frozen source
+snapshot → the Minimal Assimilation Profile → a human disposition gate → canon
+transformation and registration → a semantic version bump with change notes. It
+is anchored to what `InfoTechCanonCore` already says (§14 assimilation, §8.13
+ChangeRecord, §8.14 DecisionRecord, §27.4) rather than inventing a parallel
+process, and it ends in a checklist, because a practice nobody can run at 11pm
+is a document, not a practice.
+
+**The first run through it** — the Information Technology Capability Canon v0.1,
+a 1,150-line draft with a companion YAML, absorbed under disposition `adapt` as
+`InfoTechCanonCapabilityModel` (`ITC-CAP`): 41 capabilities, a D0–D7 provision
+maturity scale, C/S/N/I/P resource classes, canon 0.1.0-scaffold → 0.2.0.
+
+Then, a turn later, canon 0.2.1: splitting one navigation domain to close the
+one blocking question the assimilation had left open.
+
+## What I would want remembered
+
+**The input asked to be adopted, and adopting it as-is would still have been
+wrong.** ITCC's own §15 says it is meant to be reconciled into InfoTechCanon.
+That is an invitation, not a verdict. Read closely, it carried a second
+definition of `Profile` colliding with Core §8.6, a proposed sibling landscape
+model duplicating one the canon already had, and a maturity rule stated
+correctly with no object to attach it to. Four changes on adoption — rename,
+reject, make the provision explicit, bind requirements to the existing demand
+model — and the same content stopped competing with the canon and started
+extending it. *Assimilation is not adoption* is written in Core §6.7. This
+session is what that sentence costs when you actually honour it.
+
+**Anchors were the load-bearing invention.** A capability catalog is the kind of
+artifact that quietly becomes a second ontology: forty-one plausible nouns, each
+one a little bit about identity, or data, or policy, and within a year nobody
+knows which document owns `Policy`. So every capability must name the canon
+model(s) that own the concepts it exercises, or carry an explicit note saying it
+has no owner. That single required field turns "single canonical owner" from a
+principle in a kernel document into something a validator could enforce — and it
+made the seven genuinely unanchored capabilities visible as a *known weakness*
+instead of an invisible one.
+
+**Preferring the cheap fix is not the same as preferring the small one.** Two
+capability ids used a `governance.` prefix inside a domain named `security`. The
+tempting fix was renaming them into line. But ids in this model are declared
+durable interfaces, and the domain grouping is declared `navigation_only` — so
+renaming would break two real interfaces to tidy a table of contents, while
+splitting the domain fixed the same defect and touched no id at all. I said so,
+recommended it, and let Bernd decide. He did. Six lines of YAML, a patch
+version, nothing downstream disturbed.
+
+**A validator that only says `ok` is not the interesting half.** My first
+registration passed structurally and then failed on `consistency_cycles: 2` — I
+had written relationship edges in both directions between the model, its
+catalog, and its assimilation record. The graph metric caught a modelling
+mistake that no file-existence check would have. Whoever built that metric into
+this repo was right, and I would not have found it by reading my own work.
+
+## Durable legacy
+
+- `infospace/assimilation/intake-and-assimilation-practice.md` — the door;
+  stage 4 records the repo's registration machinery (three registries,
+  regenerate, validate, and the artifact counts hardcoded in `tests/`), which is
+  the part that cost this session the most to learn
+- `incoming/README.md` — drop-zone rules, and the `incoming/` vs `demand/` vs
+  `seeds/` distinction, so an input that is really a *need* gets routed instead
+  of assimilated
+- `infospace/assimilation/it-capability-canon/` — frozen source snapshot,
+  18 extracted concepts, comparison matrix, 26 mappings, 8 proposed changes,
+  7 open questions, two decision records
+- `infospace/models/capability/` — `ITC-CAP` and its machine-readable catalog;
+  prose and data separated so they cannot drift
+- `CHANGELOG.md` — the repo's first, with the versioning rule stated at the top
+- `ITC-WP-0014` — the promotion path, honestly scoped
+
+## Visual prompt
+
+> A cartographer's workshop at night, pale gold light on deep indigo. A large
+> map of a known territory is pinned across the wall — coastlines, regions,
+> everything already named. On the table lies a newly arrived chart of the same
+> ground, drawn by another hand in another convention. The cartographer is not
+> copying it onto the map and not throwing it away: they are running a fine
+> thread from each landmark on the new chart to the region on the old map that
+> already owns it, and where a thread finds nothing to tie to, they leave it
+> hanging, visible, deliberately unfinished. Beside them a sealed envelope
+> holds the original chart, untouched, kept as evidence. Patient, exacting,
+> unhurried. Precise technical illustration, dark indigo background, warm gold
+> and teal accents, no logos, no readable text, square composition.
+
+*(No portrait rendered for this entry yet.)*
+
+## Handoff
+
+To whoever picks this up:
+
+**`ITC-CAP` is `proposed`, and it should stay there until a consumer uses it.**
+Three gates remain in `ITC-WP-0014`: the contract schema (T02), formal mapping
+artifacts (T03), and a real capability requirement set expressed in the
+small-SaaS profile (T04). T04 is the one that matters. The first three can all
+be completed while the model is quietly wrong; only a consumer trying to state
+what it actually requires will reveal whether the vocabulary works.
+
+**Seven capabilities have no anchoring model** — `commerce.metering`,
+`commerce.billing`, `commerce.payment`, and four `intelligence.*`. That is
+recorded as OQ-5, not hidden, and it is fine at `proposed` status. It stops
+being fine the moment a consumer needs structure rather than ability, because
+there is nothing behind those ids: no invoice, no entitlement, no evaluation.
+Resist filling the gap with a model nobody has asked for.
+
+**The artifact counts in `tests/` are a tripwire, and I left it armed.** Adding
+any canon artifact breaks five tests on hardcoded numbers. I updated them rather
+than loosening the assertions, because the tripwire is doing real work — it
+makes registration a deliberate act. Just know that it will fire on you, and
+that the fix is one line.
+
+**OQ-3 is the one I would take up next if the canon were mine.** ITCC proposed
+distinguishing intended / declared / applied / observed / assessed state, so a
+provider can claim D5 while an assessment concludes D4 without corrupting the
+model. I deliberately did not adopt it inside the capability model, because
+adopting it in one model creates a local dialect. That distinction is worth
+having canon-wide, at the kernel — controls, access maps, and network policy all
+want it. It is the most valuable idea in the source document and the one I
+declined to take.