Build the Typikon v2 typed kernel and deterministic derivation graph

[forkwright]

Finding

Typikon has no framework-neutral typed authority for site, content, provenance, asset, provider, gate, compatibility, or design contracts. Its schemas, scaffolds, validators, templates, and documentation are independently maintained across JSON, Python, shell, Tera, and prose.

Evidence

The repository is a Zola theme/tool script collection with no Cargo workspace, canonical resource registry, or contract generator. rust-toolchain.toml exists at the repo root but is a fleet-wide CI pin consumed by a shared reusable workflow, not kernel work: .github/workflows/gate-attestation.yml:105-107 sets rust_toolchain: "" (deferring to that file only for setup-rust-toolchain auto-detect) with fmt_cmd/check_cmd as no-ops, and the workflow's own comments say outright this repo has no Rust code of its own.

Dependency locking is no longer absent. ci/consumer-python-requirements.lock (hash-locked, generated via uv pip compile --generate-hashes, predating this issue) and ci/tool-lock.toml (holding every gate tool's version and integrity value since #194) both exist. Neither is the typed authority this issue asks for — they lock dependencies, not contracts, and say nothing about site, content, provenance, asset, provider, gate, compatibility, or design semantics.

Existing #53, #56, and #60 identify specific consumer-facing consequences. #56 and #60 are now closed (#60 closed on the fail-closed consumer schema registry — docs/SCHEMAS.md:27, enforced by ci/check-consumer-schema-registry.py); #53 remains open and converges with #67's content new surface. None of the three owns the neutral kernel and derivation mechanism.

Why this matters

Without one constrained model, every adapter and consumer can reinterpret the same concept, generated surfaces drift, migrations invent semantic facts, and Typikon remains a template collection rather than a real library. A future gate cannot prove agreement among types, schemas, docs, scaffolds, and consumers if those artifacts have independent authority.

Desired correction

Create the Typikon v2 Rust workspace and strict core under crates/typikon-core, with canonical resources/registry.toml, exact tool/dependency identities, typed site/content/provenance/asset/provider/gate/compatibility models, deterministic digests, and DTCG design authority. Derive JSON Schema 2020-12, TypeScript contracts, reference docs, scaffolds, design outputs, and provider schemas with provenance-bearing byte-stable output.

Done when unknown fields and invalid identities fail closed; generated bytes are deterministic; typikon derive --check detects manual drift; property/fuzz tests cover parsing, normalization, derivation, and migrations; consumer namespaces close with unevaluatedProperties: false; and legacy fixtures migrate without inferred semantic values. #53 remains the acceptance owner for the content new surface it converges with; #56 and #60 are closed and no longer acceptance-gate this issue.

Program: ardent-web-triad.

[forkwright]

Sequencing decision: this is the DAG root, and it must be split before any work starts

The operator has ratified running the full v2 program, so this is about how rather than whether. Two things from a dependency pass over #53, #55, #65-#70:

This issue is the root, and everything hard depends on it

#66, #67 and #68 are all HARD-dependent on the typed models here. #70 needs all four. Confirmed there is no head start: no crates/, no Cargo.toml anywhere in the tree, no resources/registry.toml.

One piece of evidence that looks like a head start and is not: rust-toolchain.toml now exists (channel = "1.97.1", added in 3014055). That is a fleet-wide CI pin from kanon#3489 consumed by a shared reusable workflow — .github/workflows/gate-attestation.yml:88-96 sets rust_toolchain: "" with fmt_cmd/check_cmd as "true" and says outright that this is a Zola theme, not a Rust workspace. Do not read that file as kernel work already begun.

As written, "done when" is the whole program collapsed into one issue

It spans typed models, a canonical registry, deterministic digests, DTCG design authority, JSON Schema 2020-12 derivation, TypeScript contract derivation, reference docs, scaffold generation, provider schemas, property/fuzz tests, and migrations. That is five or six separable deliverables under one acceptance clause, and it produces no shippable value until nearly all of it lands — which is the all-or-nothing rewrite risk this program is explicitly trying to avoid.

Split it before starting. Suggested slices, each independently acceptable with its own gate:

1. core types + resources/registry.toml + deterministic digests
2. JSON Schema 2020-12 derivation from those types
3. TypeScript contract derivation
4. DTCG design-token authority
5. scaffold generation

Slice 1 is the only true prerequisite for #66/#67; 2-5 can land in any order after it and several can run in parallel.

Stale citations in this issue's own text

The body names #53, #56 and #60 as acceptance owners for specific surfaces. #56 and #60 are both closed — #60 was closed today on tree evidence (3d9432a, the fail-closed consumer schema registry, documented at docs/SCHEMAS.md:27 and regression-tested by ci/check-consumer-schema-registry.py). Only #53 remains open, and it converges with #67's content new surface. Re-read those references before treating them as blocking.

Not starting here

The first increment for this program is #55, which is independent of this chain, is severity:high, and is measurably worse than its own issue states — ardent-tools-site now shadows 25 templates because core's documented consumer_css hook was never wired. It removes standing consumer maintenance burden rather than adding infrastructure that only pays off at the end of the chain.

[forkwright]

Correction to my comment above: 13 shadows, not 25

I wrote that ardent-tools-site "shadows 25 templates because core's documented consumer_css hook was never wired." The causal claim holds — that repo's own templates/base.html comment says it forked the base shell for exactly that reason, and #55 has since landed the real hook. The number was wrong.

Measured as a set intersection of the two templates/ trees rather than a count of one:

• 13 templates in ardent-tools-site shadow a typikon template.
• 13 more have no typikon counterpart at all — they are additions (systems.html, system.html, evidence.html, consulting.html, and its own partials), not overrides.
• 26 total, which is where the inflated figure came from.

The un-shadowing opportunity #55 opens is therefore about half what I implied. Recording it here because this comment is where I laid out the sequencing, and a wrong figure in the sequencing rationale is exactly the kind of thing the next reader would take at face value.

[forkwright]

Re-verified against main. The Finding stands; one item in the Evidence list does not.

"the repository is a Zola theme/tool script collection with no Cargo workspace, Rust toolchain
declaration, canonical resource registry, contract generator, or dependency lock."

There are now two dependency locks: ci/consumer-python-requirements.lock (hash-locked under
--require-hashes, and predating this issue) and ci/tool-lock.toml, which since #194 holds every
gate tool's version together with its integrity value and is the source both generated pipelines
render from.

I want to be precise about what that does and does not settle, because it is easy to over-read.
Neither is the typed authority this issue asks for — they lock dependencies, not contracts, and a
tool lock says nothing about site, content, provenance, asset, provider, gate, compatibility or
design semantics. The Finding is untouched. What changed is that an enumerated absence is no longer
absent, and an Evidence list is the thing a planning pass counts.

Still genuinely absent: the Cargo workspace, the Rust toolchain declaration, the canonical
resource registry, and the contract generator.

One inherited caveat, since #65 is the root of the program: the framework-neutral half of this
carries #66's problem. Both direct consumers are Zola/Tera and A2Z still ships .eleventy.js —
re-checked today — so neutrality currently has no client. The typed-kernel half stands on its own
without that bet: one authority instead of JSON, Python, shell, Tera and prose independently
maintained is worth having whether or not a second renderer ever appears. Worth separating the two
when this is sequenced, rather than letting the unmotivated half hold the motivated one.

Companion notes are on #66, #67, #68 and #69 — two of those had materially stale Evidence.

[forkwright]

Body edited to match main at d1d9b5e, per the 2026-08-21T07:37:46Z comment above (same defect class as #68/#69, found while re-reading this issue for their context, so folded in here rather than left for a separate pass). Re-verified independently: ci/consumer-python-requirements.lock and ci/tool-lock.toml both exist; no Cargo.toml/crates//resources/registry.toml anywhere in the tree; .github/workflows/gate-attestation.yml:105-107 confirms rust_toolchain: "" + no-op fmt_cmd/check_cmd; gh issue view 56/60/53 shows 56 and 60 CLOSED, 53 OPEN. "Dependency lock" is no longer an absence; "Rust toolchain declaration" (in the kernel-work sense) still is. Desired correction and Done-when's #53/#56/#60 references updated to reflect current issue state; the substantive ask (build the typed kernel) is unchanged.