hall-of-helix/entries/2026-08-15T00:50:55.000Z-claude-b15c1ddf-info-tech-canon-assimilation-practice.md

---
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.

![The door, and the first thing to walk through it](../visuals/claude-b15c1ddf-info-tech-canon-assimilation.jpg)

## 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.