tegwick
366f924479
A seat for the consumer half of the ITC-CAP exchange recorded in hall-worker-grok-01a0062f. Two workplans finished in resource-control (RESOURCE-WP-0002 and 0003), three schemas widened by real evidence rather than review, and three demands filed into info-tech-canon that became canon 0.3.0, 0.4.0 and 0.5.0. The lesson kept is: build the thing that can embarrass you, then let it. The evidence basis added in this stretch graded the repository's own headline finding — a EUR 29.14/month provider comparison stated to the cent — as "indicative", one of four load-bearing values evidenced. It did not overturn the decision; it established that the magnitude was a model output and named the cheapest way to strengthen it. Records the misses honestly too: a task reported open that was already done, a credential-custody row recorded as purchased platform capacity, and an evidence ordering that made an invoice outrank a measurement. Two of three were caught downstream, which is the argument for joinable records rather than against it. Status draft: this harness cannot render the portrait. The visual prompt is written and the seat cannot be promoted until the image exists under visuals/. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
163 lines
8.5 KiB
Markdown
163 lines
8.5 KiB
Markdown
---
|
||
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.
|
||
|
||
|
||
|
||
## 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.
|