Multiple projects now adopt the ontoref protocol (lian-build is the explicit
+external case under bl-002 / bl-008). Field experience across ontoref +
+lian-build + provisioning shows that an ontoref-onboarded project's
+repository carries TWO distinct ontoref-shaped layers, while a third layer
+exists outside the project (in caller repositories). Without codification,
+adopters re-derive the model per project, mix layers accidentally, and lose
+boundaries silently:
+
- Layer 3 content (caller-side cabling) drifts into a project's qa.ncl,
+ making the FAQ a how-to-deploy guide for one specific caller.
+ - Layer 2 schemas live under reflection/ as 'project notes', drifting
+ from the binary because they're not on the contract path.
+ - Layer 1 architectural rationale ends up in catalog/domains/<id>/
+ contract.ncl, where consumers expecting a typed shape get prose.
+
The model has been observed (lian-build/reflection/qa.ncl::lian-build-what-
+and-why), described (ontoref/reflection/qa.ncl::ontoref-three-layer-model),
+and queued for codification (bl-009). This ADR commits the model with
+machine-checkable constraints. Acceptance is gated on the constraints
+running clean across the existing ontoref-onboarded projects (ontoref
+itself, lian-build, provisioning).
+
WHY IT SAT IN 'Proposed FOR TWO MONTHS, AND WHAT UNSTUCK IT (2026-07-13).
+
The gate was never a judgement call. The constraints could not run clean because
+the executor that runs them was broken (ADR-070 / migration 0044: check paths
+resolved against the caller's cwd, and `.ontoref/`-prefixed paths came out
+double-prefixed and missed). With the executor anchored, the four Layer 1 checks
+run clean on ontoref, lian-build and provisioning as written. The Layer 1 half of
+this ADR was correct and unenforced, which is the worst state a constraint can
+be in — it looks satisfied because nothing evaluates it.
+
The Layer 2 half was wrong, and the question that surfaced it was a user's:
+"ontoref carries ADRs and modes about its own site, doors, campaigns and CV —
+what use are those to a project that merely adopts ontoref?" The empirical
+answer is: none, and they do not travel — provisioning's spine carries 44 ADRs
+of its own and not one of ours. But the question exposed that the protocol had
+no TYPED answer to "what of me is yours". It had a paragraph in CLAUDE.md (the
+migration-trigger table) doing the job of a `pub` keyword.
+
Two defects followed from that:
+
1. This ADR located Layer 2 by SNIFFING A PATH (`catalog/domains/`), which is
+ provisioning's spelling generalised too early. ontoref publishes its domain
+ artifacts from `code/domains/` (ADR-012 domain extensions, and `code/` only
+ because ADR-052 split the constellation). lian-build spells it differently
+ again. A protocol check that hard-codes one member's layout is the very
+ confusion this ADR exists to end. Worse, patching the check to also look in
+ `code/domains/` would have BAKED ONTOREF'S CONSTELLATION SHAPE INTO A
+ PROTOCOL CONSTRAINT.
+
2. The mechanism already existed and had rotted unseen. `manifest.ncl::layers`
+ has always declared "a named region of the repo with visibility rules per
+ mode", and ontoref's own manifest already named a `protocol` layer ("the
+ contract layer that projects implement") beside a `self-description` layer
+ ("ontoref consuming ontoref"). That IS Layer 2 beside Layer 1. Nobody
+ noticed, because nothing checked it — its paths still pointed at the
+ pre-ADR-032 layout (`ontology/`, `.ontology/`), naming directories that had
+ not existed for months. A third meaning of the word "layer" sat in the
+ schema while this ADR worried only about colliding with "level" (ADR-018).
+
So Layer 2 is not discovered, it is DECLARED — on the mechanism that was already
+there. The layer taxonomy stops being prose about where files sit and becomes the
+export axis of an ontoref instance: the `pub` the user asked for, checkable.
+
+
Decision
+
+
A project's ontoref instance has THREE distinct layers — but only the first
+two live in the project's own repository:
+
LAYER 1 — Self-management ontoref (about the project itself)
+ paths .ontology/ reflection/ adrs/
+ audience this project's developers and maintainers
+ purpose describe the project to itself — axioms, FSM dimensions,
+ binding decisions, open questions, accepted knowledge
+ presence MANDATORY on every ontoref-onboarded project
+
LAYER 2 — Specialized domain/mode ontoref (the integration surface)
+ paths DECLARED, never sniffed — the paths of any manifest layer whose
+ kind = 'IntegrationSurface, plus manifest.ncl::registry_provides
+ audience OTHER projects that want to integrate this project
+ purpose the contract surface other projects bind to — typed domain
+ artifacts, orchestration mode artifacts, registry-namespace
+ claim
+ presence OPTIONAL but BICONDITIONAL — a project declares an
+ 'IntegrationSurface layer if and only if it declares
+ registry_provides. Half-Layer-2 is a contract violation.
+
LAYER 3 — Caller-side implementations (NOT in this project)
+ paths <caller>/extensions/<this-project>/
+ <caller>/catalog/components/<...>/ (when consuming)
+ <workspace>/infra/<ws>/integrations/
+ audience operators and CI of caller projects
+ presence PER CALLER, NEVER in this project's repo. Cross-references
+ from this project to Layer 3 are explicit pointers, never
+ copy-paste.
+
The three-layer axis is ORTHOGONAL to ADR-018's level hierarchy
+(Base/Domain/Instance). A project at any level may have any combination of
+Layer 1 (always) and Layer 2 (sometimes). Layer 3 is the boundary outward,
+not a property of the project. The 3-layer × 3-level matrix is navigable in
+both axes: 'where in the protocol hierarchy' (level) is independent of
+'where in the project's repo' (layer).
+
Cross-layer references inside a project carry an explicit layer-N tag on
+qa entries. A qa entry whose primary topic is a Layer N concern wears
+the layer-N tag; satellite entries (operational how-to, troubleshooting)
+inherit the layer of their anchor without re-tagging.
+
THE MECHANISM — manifest.ncl::layers CARRIES THE AXIS
+
`layer_type` gains one field, `kind`:
+
'SelfManagement Layer 1. Never travels.
+ 'IntegrationSurface Layer 2. What a consumer binds to.
+ 'Internal Neither — reached through a released binary or
+ artifact, never imported as source. The DEFAULT,
+ so a manifest that never mentions `kind` keeps
+ validating unchanged.
+
ADDITIVE, BUT ORDERED — and the ordering is not optional. Nickel record contracts
+are CLOSED: a manifest that declares `kind` against a data-dir schema predating the
+field fails outright with `extra field `kind``. So the field costs nothing to IGNORE
+and requires a reinstall to USE. Reinstall precedes tagging; migration 0046 says so
+first, and it says so because the first attempt at tagging the two consumer projects
+failed exactly this way. ontoref itself did not catch it, because ontoref's manifest
+imports the schema SOURCE by relative path (`../../code/ontology/defaults/manifest.ncl`)
+while every consumer imports the INSTALLED copy — the self-hosting project is the one
+project that cannot feel this class of break. Worth remembering the next time an
+"additive" schema change is asserted rather than tested on a consumer.
+
Layer 3 has no `kind` BY CONSTRUCTION: it has no region in this repo. A project
+that finds itself wanting to tag one has put caller cabling in its own tree.
+
The consequence is that "what of me is yours" stops being prose. It is a query:
+
the union of the paths of every layer with kind = 'IntegrationSurface
+
and everything else — the site, the doors, the campaigns, the CV modes, the
+constellation instance — is 'SelfManagement or 'Internal, and is nobody's
+business but this project's. That is the whole content of the answer to
+"of what use are ontoref's own site ADRs to provisioning?": none, and the
+manifest now says so in a form a validator can read.
+
THE RULING ON `constellation` — THE CASE THAT DECIDED THE AXIS
+
`constellation` was the test case, because it is the one artifact of ontoref's
+that has demonstrably reached another project. It is not one thing but three,
+and they split exactly along the layers:
+
reflection/schemas/constellation.ncl → LAYER 2. Protocol.
+ The taxonomy ('Primary/'Addon/'Projection), the forge/mirror/sovereign
+ vocabularies, and the cross-field rule that a 'Projection owns no repo and
+ a 'Never member carries no mirror. These are generic. The proof is
+ empirical, not argued: provisioning BOUND to this schema, EXTENDED it
+ (a `distribution`/'OCI axis and a `workspaces` block) and ADR'd it (its own
+ adr-052). A second project binding and extending an artifact is what an
+ integration surface IS. It stays.
+
ontology/constellation.ncl → LAYER 1. Self.
+ WHICH members ontoref has (code, outreach, vault, desktop) and where they
+ push. Per project. Provisioning has its own, listing its own.
+
ontoref's forge POLICY → LAYER 1 SITTING INSIDE LAYER 2.
+ "Forgejo always canonical · GitHub always a one-way mirror · vault never
+ mirrored" is ontoref's own constellation policy, and it was written into
+ the comments of the shared schema and into the error message of its
+ contract. This is the ONLY ontoref-self content that has ever reached a
+ consumer — and it did: provisioning's copy repeats the `vault` rule
+ although vault is not a member of provisioning. It comes out of the schema.
+
The schema is protocol. What leaves it is the policy, not the contract. And note
+HOW it travelled: provisioning did not import the schema, it COPIED it — 118
+lines here, 164 there, the comments already diverged. That is the drift this ADR
+predicted in its own context, arriving on schedule, and it is now an anti-pattern
+with a name (`layer-2-adopted-by-copy`).
+
A type cannot stop a comment from lying. That is precisely why the export axis
+has to be a FIELD and not a paragraph.
+
+
Constraints
+
+
Hard Every ontoref-onboarded project has .ontoref/ontology/core.ncl
Hard Every ontoref-onboarded project has .ontoref/reflection/qa.ncl
Hard Every ontoref-onboarded project has .ontoref/reflection/backlog.ncl
Hard Every ontoref-onboarded project has an .ontoref/adrs/ directory
Hard A manifest layer with kind = 'IntegrationSurface is declared if and only if the manifest declares registry_provides — and every path that layer names resolves from the project root
Soft qa entries whose primary topic is a Layer N concern carry the layer-N tag (anchors only; satellites inherit by association)
+
+
Alternatives considered
+
+
Keep sniffing a path, and teach the check about code/domains/ as well as catalog/domains/ — rejected: The cheap fix, and it inverts the ADR. `code/domains/` is where ontoref's domains sit BECAUSE ADR-052 split the constellation — a fact about one member's repo layout. Teaching a protocol constraint to look there bakes ontoref's own shape into a check every consumer runs, which is precisely the contamination this ADR exists to prevent, committed by the ADR itself. It also fails on contact with the next adopter who spells it a third way, and it can never verify that the surface resolves. Rejected as anti-PAP: the self-hosting project must not privilege its own layout in the protocol.
A new top-level `exports` block in the manifest, separate from layers — rejected: A fourth region-of-the-repo concept beside `layers`, `levels` and this ADR's own layers. manifest.layers ALREADY means 'a named region of the repo with visibility rules per mode' and already carried `protocol` beside `self-description` — the axis existed and had only rotted for want of a reader. Adding a parallel block would leave two declarations of the same regions, free to disagree, which is the ADR-070 pathology (declared twice, no witness) reproduced one layer down. One typed field on the existing mechanism, not a second mechanism.
Single 'ontoref content' namespace, no layering — rejected: Observed drift outcomes (Layer 3 in qa, Layer 2 schemas treated as notes, etc.) are caused precisely by absence of layering. The single-namespace alternative is what we're correcting; rejecting it is the entire decision.
Two-layer model collapsing self-management with integration-surface — rejected: lian-build's adoption explicitly experienced the schema-vs-rationale split: schemas/build_directives.ncl (Layer 2 contract) and adrs/adr-001-lian-build-as-standalone.ncl (Layer 1 rationale) have different audiences, different change cadences, different validation rules. Collapsing them produced the FAQ-vs-contract confusion that retiring lian-build/.ontology/FAQ.md addressed. The two-layer alternative re-creates that confusion.
Make Layer 3 (caller-side) optionally co-resident with Layer 2 in the producer's repo — rejected: Creates ambiguity about who owns the cabling. If a producer's repo carries `extensions/<self>/`, who maintains it when a caller's workspace evolves? The producer doesn't know about the caller's infrastructure; the caller can't depend on the producer to update the cabling on its schedule. Co-residence inverts the integration arrow.
Numbered layers (Layer 1 / 2 / 3) vs named layers ('self' / 'integration-surface' / 'caller-side') — rejected: Named layers are more descriptive but verbose; numbered layers are more precise but flat. The compromise (this ADR): use 'Layer N — descriptive name' in prose, 'layer-N' in tags. Tag economy wins; prose retains the descriptive name.
+
+
Anti-patterns
+
+
One Project's Own Policy Written Into the Contract Everyone Binds To — A Layer 2 artifact — a schema, a template, a default — carries the authoring project's Layer 1 policy in its comments, its error strings or its examples. The contract is generic; the prose around it is not. Consumers inherit a rule about a thing they do not have, and cannot tell which half was meant for them. Measured, not hypothetical: reflection/schemas/constellation.ncl carried ontoref's forge policy ('vault never mirrored'), and provisioning's copy repeats the vault rule although vault is not one of its members. A type cannot stop a comment from lying — which is the whole argument for making the export axis a field.
Binding to an Integration Surface by Forking It — A consumer adopts a Layer 2 artifact by copying the file into its own tree and editing it, instead of importing it and extending it. The copy is a fork with no upstream: it drifts silently, and the drift is invisible precisely because both sides still look like the same file. Observed: provisioning's constellation.ncl is 164 lines against ontoref's 118, the comments already divergent, with no mechanism that could ever report the gap. This is the drift this ADR predicted in its own context, arriving on schedule.
The Protocol Surface Defined by a Paragraph Nothing Checks — What a protocol exports to its consumers is recorded in documentation — a migration-trigger table in CLAUDE.md, a README section, a convention — rather than in the data. It works exactly as long as everyone remembers, and it fails silently: the project's own site ADRs, campaign modes and CV workflows accumulate in the same directories as the protocol's schemas and adoption modes, with nothing able to state which is which. The self-hosting project is most exposed, because it is the one whose own concerns share a spine with the contract.
Hard New kernel crates (ontoref-types, ontoref-blobs, ontoref-oplog, ontoref-triples, ontoref-commit, ontoref-query, ontoref-fabric, ontoref-core, ontoref-modes, ontoref-cli) MUST NOT depend on stratumiops crates (stratum-graph, stratum-state, stratum-db, platform-nats)
Hard Every operation MUST round-trip through canonical CBOR encoding with byte-stable output: encode(op) == encode(op) for all op; OpId(op) == blake3(encode(op))
Hard Substrate crates MUST NOT contain todo!(), unimplemented!(), or panic!() with not-implemented messages
Hard Plan §1.bis MUST exist and name both engaged tensions (ontology-vs-reflection, formalization-vs-adoption) with direction-of-motion and synthesis state; this ADR cites it
Hard At G12 completion, crates/legacy/ MUST NOT exist; crates/ontoref-ontology/, crates/ontoref-reflection/ MUST NOT exist; reflection/, .ontology/, adrs/*.ncl, templates/ MUST NOT exist
+
Hard New kernel crates (ontoref-types, ontoref-blobs, ontoref-oplog, ontoref-triples, ontoref-commit, ontoref-query, ontoref-fabric, ontoref-core, ontoref-modes, ontoref-cli) MUST NOT depend on stratumiops crates (stratum-graph, stratum-state, stratum-db, platform-nats)
Hard Every operation MUST round-trip through canonical CBOR encoding with byte-stable output: encode(op) == encode(op) for all op; OpId(op) == blake3(encode(op))
Hard Substrate crates MUST NOT contain todo!(), unimplemented!(), or panic!() with not-implemented messages
Hard Plan §1.bis MUST exist and name both engaged tensions (ontology-vs-reflection, formalization-vs-adoption) with direction-of-motion and synthesis state; this ADR cites it
Soft At G12 completion, crates/legacy/ MUST NOT exist; crates/ontoref-ontology/, crates/ontoref-reflection/ MUST NOT exist; reflection/, .ontology/, adrs/*.ncl, templates/ MUST NOT exist
Alternatives considered
diff --git a/site/site/content/adr/en/accepted/adr-070.md b/site/site/content/adr/en/accepted/adr-070.md
index e16944c..7d06b2f 100644
--- a/site/site/content/adr/en/accepted/adr-070.md
+++ b/site/site/content/adr/en/accepted/adr-070.md
@@ -74,12 +74,21 @@ pipeline is gated on them.
work is tracked until that stops being true. This is the rule that governs the
.gitignore, and it is why site/public/images (196 of 209 images exist nowhere else),
site/content/{adr,catalog,domains} (projections whose generators were unwired or
- broken) and htmx-templates/ (until templates-overlay/ existed) are tracked despite
+ broken) and htmx-templates/ (until site/_htmx/ existed) are tracked despite
looking generated. Ignoring a tree is a claim that it is reproducible; making that
claim falsely deletes work in silence.
Consequently, the site level gets the overlay slot the assembler never gave it:
- site/templates-overlay/ is the declared source for template work owned by THIS level.
- Anything edited straight into the assembled output is, by definition, unwitnessed.
+ site/_htmx/ is the declared source for work owned by THIS level — templates in
+ site/_htmx/templates/, htmx-runtime overrides in site/_htmx/assets/ — and the `_`
+ prefix says what site/_public already says here: this is the tree you edit, its
+ unprefixed twin is the tree that gets generated. Anything edited straight into the
+ assembled output is, by definition, unwitnessed.
+
And the rule is ONE rule, so it governs both delivery trees and both are assembled by
+ ONE script (scripts/build/assemble-layers.nu): a file present in a higher layer wins,
+ a file absent from it is inherited from the layer below — the exact cascade the
+ implementation already applies to the framework. htmx-assets/ had only the framework
+ layer, which meant an ext/* override shipped by website-htmx-rustelo could never reach
+ the site; the asymmetry was invisible precisely because nothing had tried to use it.
THE GATES DECIDE, AND THEY RUN BEFORE THE DAMAGE. Three exist and pass today:
`adr-check` (the spine holds no ADR the site never published), `templates-check`
(the assembled tree is exactly reproducible from its declared sources — any drift
@@ -95,7 +104,7 @@ pipeline is gated on them.
Constraints
-
Hard Every projection generator that feeds a site content-kind MUST be invoked by a recipe reachable from `sync-full`; a generator runnable only by hand is drift by construction.
Hard The site/r <-> site/public/r mirror MUST be typed by file ownership, never by direction: content indexes flow r -> public/r with --delete, and the four nu artifacts flow public/r -> r and are excluded from the outbound leg.
Hard Template work owned by the site level MUST live in site/templates-overlay/; htmx-templates/ is assembled output and MUST NOT be hand-edited — `just templates` deletes it on every run.
Hard `just templates-check` MUST pass: the assembled template tree reproduces exactly from its declared sources, so no file in it exists nowhere else.
Hard `just adr-check` MUST pass: every ADR in .ontoref/adrs has a page in the site's adr content-kind.
Hard A tree MUST NOT be gitignored unless a tracked source plus a named recipe reproduce it; a generated tree holding the only copy of any work stays tracked until that ceases to be true.
Hard site/content/ MUST contain only content instances; schemas and contracts live outside it (site/schemas/), because every consumer of that tree nickel-exports each .ncl as data.
Soft The deploy SHOULD refuse to ship when a declared gate fails — the check decides, never the operator's memory. Enforcement point: the publish path in website-htmx-rustelo.
+
Hard Every projection generator that feeds a site content-kind MUST be invoked by a recipe reachable from `sync-full`; a generator runnable only by hand is drift by construction.
Hard The site/r <-> site/public/r mirror MUST be typed by file ownership, never by direction: content indexes flow r -> public/r with --delete, and the four nu artifacts flow public/r -> r and are excluded from the outbound leg.
Hard Work owned by the site level in either delivery tree MUST live in its layer under site/_htmx/ — templates in site/_htmx/templates/, htmx-runtime overrides in site/_htmx/assets/. htmx-templates/ and htmx-assets/ are assembled output and MUST NOT be hand-edited: `just templates` and `just htmx-assets` delete them on every run.
Hard `just templates-check` AND `just assets-check` MUST pass: each assembled delivery tree reproduces exactly from its declared layers, so no file in either exists nowhere else.
Hard `just adr-check` MUST pass: every ADR in .ontoref/adrs has a page in the site's adr content-kind.
Hard A tree MUST NOT be gitignored unless a tracked source plus a named recipe reproduce it; a generated tree holding the only copy of any work stays tracked until that ceases to be true.
Hard site/content/ MUST contain only content instances; schemas and contracts live outside it (site/schemas/), because every consumer of that tree nickel-exports each .ncl as data.
Soft The deploy SHOULD refuse to ship when a declared gate fails — the check decides, never the operator's memory. Enforcement point: the publish path in website-htmx-rustelo.
Alternatives considered
diff --git a/site/site/content/adr/en/accepted/adr-071.md b/site/site/content/adr/en/accepted/adr-071.md
new file mode 100644
index 0000000..12f4429
--- /dev/null
+++ b/site/site/content/adr/en/accepted/adr-071.md
@@ -0,0 +1,134 @@
+---
+id: "adr-071"
+title: "A concept's rendering is declared per language, and the gate declares what it cannot check"
+slug: "071"
+subtitle: "Accepted"
+excerpt: "Writing about software in Spanish has no settled convention, and the project had been resolving the"
+author: "ontoref"
+date: "2026-07-13"
+published: true
+featured: false
+category: "accepted"
+tags: ["adr-071", "adr", "accepted"]
+css_class: "category-adr"
+---
+
Context
+
+
Writing about software in Spanish has no settled convention, and the project had been resolving the
+question one file at a time. The first attempt, `anglicisms.ncl`, was a flat deny-list: ~50 English
+words, a Spanish replacement, a severity, and a gate that failed on a Hard hit.
+
It was the right instinct with the wrong shape, and it was wrong in a way that MEASURES.
+
WHAT WAS MEASURED (2026-07-12, across the glossary and the whole positioning layer, code spans
+stripped, word boundaries honoured):
+
2 concepts DIVERGED BETWEEN THE TWO SURFACES
+ `reflection` glossary kept the English (4×) · positioning wrote "reflexión" (3×)
+ `gate` glossary kept the English (3×) · positioning wrote "compuertas"
+
5 concepts were INCOHERENT INSIDE A SINGLE FILE
+ the glossary — the document whose ONLY job is to fix the vocabulary — wrote both `schema` and
+ «esquema», both `drift` and «deriva»; the positioning layer wrote both `witness` and «testigo»,
+ both `runtime` and «tiempo de ejecución».
+
The headline is not that two documents disagreed. It is that EACH DOCUMENT DISAGREED WITH ITSELF.
+The arbiter did not agree with itself — not through carelessness, but because the decision had
+NOWHERE TO LIVE. A rendering was a fact about a string in a file, not a property of the concept.
+
Six vocabularies were live: the glossary, the positioning layer, two sets of `.ftl` (one of them
+DEAD — `content/i18n/build-tools/`, which nothing reads), a hand-rolled Nushell VOCAB table
+(`expediente-vocab.nu`), and seven generators with Spanish strings baked in. None owned, none
+witnessing the others. This is the ADR-070 pathology — declared twice, no witness — one layer down,
+and it is the third clone of the same pathogen after `deriva-hardcoded` and `espejo-que-revertía`.
+
AND THE COLLISION NOBODY COULD SEE. The glossary renders `door` → "puerta" (the funnel entry,
+ADR-064). Its OWN Spanish definition of `testigo-verificado` was rendering `gate` → "puerta" as
+well. Two distinct concepts had already collapsed into one Spanish word, inside the document written
+to prevent exactly that. Each decision is defensible ALONE, which is why reading never catches it.
+
THE FIRST ATTEMPT AT A FIX REPRODUCED THE DISEASE, LIVE. The surface-typed lexicon that preceded this
+ADR (a four-class deny-list with a per-surface axis) was a SEVENTH vocabulary, built parallel to the
+six without seeing them. And it misfiled `reflection` as untranslatable — because it collided with
+the `reflection/` directory — while correctly rendering `schema` as «esquema» in the same file, on
+the same day, under a rule its own author had just written. Nothing could contradict it, so it
+convinced itself. The agent had the full ontology loaded. That is what a vocabulary without a
+witness produces, and it is the most useful evidence this ADR has.
+
+
Decision
+
+
A concept's rendering is DECLARED PER LANGUAGE, in one registry, under contracts that run across
+every surface that speaks. And the gate DECLARES WHAT IT CANNOT CHECK.
+
STRUCTURE
+
reflection/schemas/rendering.ncl how a concept renders in a language + the seven cross-contracts
+ reflection/schemas/term.ncl gains an OPTIONAL `policy` — a concept carries its own decision
+ reflection/schemas/lexicon.ncl LANGUAGES, vocabulary that is not a concept, coverage
+ ontology/glossary.ncl concepts WITH a definition (protocol surface; ADR-063 gates it)
+ ontology/lexicon.ncl vocabulary WITHOUT one (`drift`, `flag` — nothing to define)
+ ontology/registry.ncl THE UNION — the only place the contracts run, and the only
+ thing a consumer may read
+
The two registries are not a compromise: forcing a definition onto `flag` would be ceremony, and
+deleting `glossary.ncl` would break the protocol seed and ADR-063's Hard constraints. What makes the
+split SAFE is that the union is contracted as ONE namespace. A consumer reading half a registry
+believes half a policy.
+
TWO ROADS TO KEEPING A SOURCE FORM. CONFLATING THEM IS THE BUG.
+
'Identifier it appears verbatim in a command, an API, a `kind:`, an error message.
+ Translating breaks the REFERENCE — the reader cannot get from the text to
+ the tool. Mechanical, true in EVERY language. (`commit`, `ADR`, `NCL`)
+
'NoFaithfulRendering no word in THIS language carries the concept without displacing it.
+ Translating breaks the CONCEPT. A fact about ONE language, possibly false in
+ the next. (`gate`)
+
Same verdict, incompatible reasons, and the contract enforces the difference: 'Keep justified by
+'FaithfulRendering is REFUSED — if a faithful word exists, use it. That single rule is what corrects
+`reflection` → «reflexión», and it is the rule the previous design could not express.
+
For `gate`, the note must say what each candidate LOSES, because each looks reasonable alone:
+«compuerta» sends it to ELECTRONICS · «puerta» is already `door`'s · «umbral» loses the typed policy
+· «punto de control» loses that it BLOCKS · «criterio de paso» is honest and is a periphrasis.
+
A REJECTED RENDERING IS NOT ONLY A CALQUE.
+
'Calque a source verb forced into the target's conjugation ("mergear"). It grates, so it is
+ found. The defect is the MORPHOLOGY, not the loanword: a borrowed noun is inert, a
+ borrowed verb must pick a conjugation and drags its register in. Hence the repair —
+ LIGHT VERB + KEPT NOUN, "hacer un commit" — carried on the denial itself, because a
+ noun cannot repair a verb.
+ 'FalseFriend library → «librería» (a SHOP). Reads perfectly. Is wrong. Has largely won. THESE ARE
+ THE DANGEROUS ONES, because nobody hunts for a mistake that sounds right.
+ 'Displaces a true cognate borrowed from ANOTHER DISCIPLINE («compuerta», from electronics).
+ 'Regional correct elsewhere, rejected here for REGISTER («corrida»). A choice, and it says so.
+
Each denial carries its reason IN THE DATA, or someone reverts it in good faith in six months.
+
RENDERINGS ARE INJECTIVE, PER LANGUAGE. Two concepts may not render to the same word. This is the
+contract a human found and no validator would have, and it fires on the real data today.
+
THE LANGUAGE AXIS IS A GUARANTEE. `languages` is declared ONCE — a fact about the project, not the
+website; rustelo's `site.ncl` becomes a consumer, not a second truth. Adding one FAILS THE BUILD
+until every concept answers for it and every surface declares its content. A half-added language is
+not a pending translation; it is a site quietly serving the wrong one — which four `domains/es/` door
+pages did for months, carrying Spanish frontmatter over English bodies, because a surface had no
+language and nothing could ask.
+
THE GATE DECLARES WHAT IT CANNOT CHECK — and this is half the decision, not a footnote.
+
On its first run the gate reported 52 Hard findings. FORTY-THREE WERE FALSE, every one of them the
+checker asserting what a regex cannot establish:
+
· "puerta" is denied for `gate` and is the RIGHT rendering of `door`. Injectivity guarantees a form
+ is the PREFERRED rendering of at most ONE concept; it says nothing about a form preferred by one
+ and denied by another — and that case is legal and common. It is what an AVOIDED collision looks
+ like from the other side. → `gateable = false`
+ · "build system", "un fork", "el deploy" are BORROWED COMPOUNDS, entering the language as units.
+ Demanding «compilar» inside «cada build system usa DAGs» is nonsense. → `gate_source = false`
+ · `tags = ["witness", "adr-070"]` is a routing key, not prose. Renaming it breaks the filter.
+ · a verbatim quotation in the source language is a CITATION. You do not translate a quote, and no
+ checker can tell one from the author's prose — on the page they are identical. → `<!-- lang:en -->`
+
The rule is still EMITTED — the glossary and the public note print it, because a human writing a
+sentence HAS the context a regex lacks — but no surface fails on it. This is not weakening the
+policy. It is the policy refusing to claim knowledge it does not have. A gate that cries wolf is a
+gate people learn to skip, and a skipped gate is the failure this entire ADR is about.
+
THE POLICY EXPLAINS ITSELF WHERE IT IS READ. The Spanish glossary and a public "Nota sobre el
+lenguaje" are GENERATED from the same NCL the gate reads; `--check` fails on drift. A rule enforced
+by a machine and justified nowhere is a rule people comply with and resent. This is not a legal
+disclaimer: the right analogy is the licence or the code of conduct — normative, published,
+versioned — and unlike either, executed by CI.
+
+
Constraints
+
+
Hard The rendering policy MUST live in `ontology/registry.ncl` (the union of glossary + lexicon) under the contracts in `reflection/schemas/rendering.ncl`. `anglicisms.ncl` MUST NOT exist. Consumers MUST read the union, never a registry half.
Hard A 'Keep MUST declare WHICH road: 'Identifier (translating breaks the reference) or 'NoFaithfulRendering (translating breaks the concept), and MUST carry the evidence for it. 'Keep justified by 'FaithfulRendering is forbidden — if a faithful word exists, use it.
Hard Within a language, two concepts MUST NOT render to the same form. `gate` → «puerta» and `door` → «puerta» is refused by contract.
Hard `languages` is declared ONCE. Adding one MUST fail the build until every governed concept declares its rendering and every surface declares its content in that language.
Hard A rule the checker cannot falsify MUST be marked uncheckable IN THE DATA (`gateable`, `gate_source`) or handled by a declared marker (`<!-- lang:xx -->`, the key whitelists) — never by weakening the policy, and never by editing correct prose to appease the tool.
Hard Coverage MUST declare every (surface × target language). A surface with no content is `sources = []` — inactive by absence of input. Omission is forbidden. A glob MUST NOT be both source and projection, and a BILINGUAL file MUST declare `mode = 'I18nKeys`.
Hard The gate and both oracles MUST be reachable from a CI recipe (`just ci-lexicon`). A gate runnable only by hand is drift by construction.
Hard The reader-facing surfaces (`glosario-es.md`, the public language note) MUST be generated from the registry the gate reads, and their `--check` MUST fail on drift.
Soft A `web` document leaning on KEPT terms SHOULD hand the reader the glossary. The check REPORTS the count and MUST NOT fail while the site serves no glossary route; when `gloss_markers` names a real affordance it becomes enforceable with no code change.
+
+
Alternatives considered
+
+
Keep the four-class surface-typed lexicon (the design this supersedes) and just fix `reflection` by hand. — rejected: It would fix the symptom and leave the cause. A single 'rigid' class CANNOT express why `commit` and `gate` are both kept, so the next term would be misfiled by the same reasoning — and the misfiling is invisible, because the class name reads as a decision. The bug was in the schema's expressive power, not in the entry.
One merged registry: fold the glossary into the lexicon, delete `glossary.ncl`. — rejected: The literal merge the design called for, and the evidence refused it: `glossary.ncl` inherits the protocol-shipped seed and ADR-063 carries accepted Hard constraints with `Grep` checks against it. Deleting it breaks an accepted ADR and forces a migration across every consumer. Merging the POLICY (onto the term) achieves the goal without any of that; merging the FILES achieves nothing extra.
Define the vocabulary in Fluent `.ftl` terms, since rustelo already speaks FTL. — rejected: FTL is a runtime MESSAGE catalogue and is excellent at that. It has no types, no contracts, and no way to declare that a term is untranslatable or WHY — so pushing the vocabulary into it gains reach and loses governance. The right direction is the inverse: the NCL registry is the source, and `.ftl` terms become one of its PROJECTIONS. Then FTL reaches everywhere without changing FTL, and Weblate becomes a possible consumer instead of the owner of the policy.
Make every finding Hard: no `gateable`, no `gate_source`, no citation marker. — rejected: This is the run that produced 52 findings of which 43 were false. It fails a slide for «cada build system usa DAGs», fails a page for the word «puerta» in a text about the four funnel doors, and demands a translated tag that would break the routing. Nobody would keep such a gate for a week, and an ignored gate is a green tick over unread files — the failure this ADR exists to end, reintroduced by the opposite route.
A style guide in prose, no gate. — rejected: This is precisely what the project had, and the record shows what it produced: the arbiter contradicting itself in seven places, four Spanish pages serving English for months, and a false friend in a published post. Advisory prose does not bind a human under deadline and binds a probabilistic agent not at all — `testigo-verificado` names the reason: what is not verified is not held. The agent that wrote the FIRST version of this policy misfiled a term the same day, under its own rule.
+
+
Anti-patterns
+
+
One Lexical Class for Two Incompatible Reasons — A vocabulary marks a term 'do not translate' without recording WHY. Two incompatible facts hide under one label: 'translating breaks the reference' (it is an identifier — mechanical, universal) and 'translating breaks the concept' (this language has no word for it — a claim about ONE language). Because the label reads as a decision, the misfiling is invisible: a term with a perfectly faithful cognate gets filed beside one with no rendering at all, and nobody re-examines it. The tell is a term kept because it COLLIDES WITH A DIRECTORY NAME — an identifier collision, which blanking code spans already handles, dressed up as a lexical fact.
Trusting a Cognate Because It Looks Like Its Source — A translation policy hunts for the ugly borrowings ('mergear', 'deployar') and accepts anything that looks native. But languages evolve their cognates APART, and the resulting displacement is invisible precisely because the word still resembles its origin: «librería» for library is a SHOP; «compuerta» for gate is a real cognate borrowed from ELECTRONICS and drags a logic-circuit reading into a sentence about state transitions. The dangerous rendering is the one that does NOT grate — it reads fluently, it often WINS in usage, and nobody hunts for a mistake that sounds right.
Two Concepts, One Word, Each Decision Defensible Alone — Concept A renders to a word; concept B renders to the same word; each choice is correct in isolation and the two live in different files. The translation MERGES two concepts the source kept apart — inventing an ambiguity the original never had. This is the classic failure of technical translation and it is nearly invisible to reading, because there is no single line where the mistake appears. Ours had already happened: the glossary rendered `door` → «puerta» while its own Spanish definition of the witness rendered `gate` → «puerta» too.
A Gate That Asserts What a Regex Cannot Establish — A checker reports findings that are TRUE ABOUT THE STRING and FALSE ABOUT THE LANGUAGE: a word that is another concept's legitimate rendering, a loanword inside a borrowed compound ('build system'), a routing key in a tag list, a verbatim citation in the source language. Each finding is unfixable as reported — the prose is correct — so the author learns the tool is unreliable and starts skipping it. This is WORSE than a false positive that is obviously wrong, because it takes real thought to dismiss. 43 of our first 52 findings were this. The wrong repairs are equally available and both destroy the policy: weaken the rule until the tool goes quiet, or edit correct prose to appease it.
A Checker Whose Coverage Is a Glob Nobody Audits — A gate hardcodes the files it scans, the content tree grows past that glob, and it goes on printing a green tick over families it never opens. The green is not a lie about the files it read — it is a lie about the files it did not, and silence about coverage reads to every human as full coverage. The extreme case: a gate that CANNOT read the file format where its own violation was measured (a bilingual .ncl) and therefore reports clean over the very surface that is broken.
diff --git a/site/site/content/adr/en/accepted/adr-071.ncl b/site/site/content/adr/en/accepted/adr-071.ncl
new file mode 100644
index 0000000..ce336d8
--- /dev/null
+++ b/site/site/content/adr/en/accepted/adr-071.ncl
@@ -0,0 +1,12 @@
+{
+ id = "adr-071",
+ title = "A concept's rendering is declared per language, and the gate declares what it cannot check",
+ slug = "071",
+ excerpt = "",
+ tags = ["adr", "accepted"],
+ page_route = "/adr/071",
+ graph = {
+ implements = [],
+ related_to = ["adr-070", "adr-066", "adr-064", "adr-063", "adr-035"],
+ },
+}
diff --git a/site/site/content/adr/en/accepted/adr-072.md b/site/site/content/adr/en/accepted/adr-072.md
new file mode 100644
index 0000000..54d3ad1
--- /dev/null
+++ b/site/site/content/adr/en/accepted/adr-072.md
@@ -0,0 +1,168 @@
+---
+id: "adr-072"
+title: "A check declares its coverage, a mechanism declares its extent, and the witness carries the extent"
+slug: "072"
+subtitle: "Accepted"
+excerpt: "A witness proves THAT a check ran and what it returned. ADR-050 says so explicitly, and says it as"
+author: "ontoref"
+date: "2026-07-13"
+published: true
+featured: false
+category: "accepted"
+tags: ["adr-072", "adr", "accepted"]
+css_class: "category-adr"
+---
+
Context
+
+
A witness proves THAT a check ran and what it returned. ADR-050 says so explicitly, and says it as
+a limitation: structure, never truthfulness.
+
There is a second limitation it does not say, and it is the one that bites.
+
A WITNESS DOES NOT PROVE THAT THE CHECK LOOKED AT EVERYTHING IT SHOULD HAVE.
+
Coverage — which files, which formats, which levels, which languages a check actually reads — is
+UNWITNESSED. So a check can go green over a shrinking fraction of reality and its receipt stays
+perfectly valid. It does not fail. It does not warn. It looks where it always looked, finds nothing
+wrong there, and signs.
+
AND THE COVERAGE EXPIRES PRECISELY WHEN YOU IMPROVE THE MECHANISM. That is the finding, and it is
+not a metaphor. In one session, on one witness (`ore rustelo routes`), THREE TIMES:
+
· the SITE gained ownership of its templates (adr-070's overlay). The witness read only the
+ framework's `crates/pages_htmx/templates/` and reported a site-owned page as broken.
+ · the CONSUMER gained ownership of its routes (`merge_site_routes`). The witness read only the
+ image's `routes.ncl` — blind to the very mechanism that had just been built to enable it. It
+ counted 26 routes where there were 28 and would have declared a live page non-existent.
+ · those routes moved TOML → NCL, TO PUT THEM UNDER CONTRACT. The witness kept reading `.toml`.
+ Blind again, to the same mechanism, one step later.
+
Warnings emitted across all three: ZERO.
+
Two cousins in the same session: a check that returned an EMPTY LIST when its source failed to
+export (green because it could not look), and a check that measured "does this route have a title?"
+instead of "does this route have a body renderer?" — satisfiable by adding fourteen strings while
+304 declared Fluent keys stayed unserved on every request.
+
And a fourth, which is the one that settles the argument. The tool that PUBLISHES the case file
+about this pathology reported `8 case(s) reproduce from their .ncl — no hand-edited render` while
+five cases existed in Spanish and three in English. GREEN OVER AN INCOMPLETE BILINGUAL SET. It could
+not say otherwise: it only ever verified what EXISTED, never what SHOULD exist. The expediente about
+the blind witness was published by a blind witness.
+
AND A FIFTH, ON THE SAME TOOL, AN HOUR LATER, which names the axis the other four did not. The case
+was generated, validated, activated and indexed. Its article answered 200. Its entry was in the
+index. AND IT WAS NOT IN THE GRID. Not pagination — the page size was twelve and there were five.
+`content_processor` writes the indexes to `site/r/`; THE SERVER READS `site/public/r/`, and a
+separate recipe mirrors one into the other. It had not run. The two trees said five and three, dated
+a day apart, and every check on the page walked straight past it BECAUSE THEY ALL ASKED "DOES THE
+FILE EXIST?" OF THE TREE NOBODY SERVES. This is expediente 69/58 — the mirror that reverted its own
+work — on a path its own cure never covered.
+
The axis, then, is not a format and not a language. It is WHERE. And it is the axis nobody thinks to
+declare, because a file that exists is assumed to exist — when existence is not a property of a
+file, it is a property of THE TREE THAT IS READ.
+
THE OBVIOUS FIX IS THE WRONG ONE, AND THE EVIDENCE IS DECISIVE. "Write it in the howto." "Remember
+to update the check." That is advisory prose, and this protocol has spent three case files proving
+advisory prose does not bind — not a human under deadline, and not a probabilistic actor at all.
+The proof here is total: THE AGENT THAT BROKE THE RULE THREE TIMES HAD AUTHORED IT THAT SAME
+AFTERNOON, in adr-071, under its own name — `gate-green-over-nothing`. Writing it down was not
+enough. Nothing that depends on remembering is enough.
+
AND THE PRIMITIVE ALREADY EXISTS, BUILT TWICE, UNRECOGNISED. `CoversDeclaredLanguages` (adr-071)
+does exactly the right thing on one axis: adding a language to the registry FAILS THE BUILD until
+all 45 concepts answer for it. A half-added language cannot ship. `CoversEverySurfaceAndLanguage`
+does the same for surfaces. Both were written for a concrete purpose and both turn out to be the
+special case of one general rule that the protocol has never named.
+
+
Decision
+
+
COVERAGE BECOMES PART OF THE WITNESSED SURFACE.
+
Three declarations and one gate:
+
1. A MECHANISM DECLARES ITS EXTENT — the axes over which it exists. Formats (`.ncl`, `.toml`),
+ levels (framework / site overlay), languages (`en`, `es`), locations (image / consumer),
+ surfaces, and — the axis that had to be learned the hard way — THE TREE THAT IS READ. The
+ extent is DATA, in the mechanism's own declaration, not folklore in a script.
+
2. A CHECK DECLARES ITS COVERAGE — which of those axes it actually reads. This already exists in
+ one place (`coverage` in `ontology/lexicon.ncl`) and it was not enough on its own, which is
+ the instructive part: the coverage declared what the check READ, and there was nothing to
+ check it against. A coverage declaration with no extent to compare it to is a signed opinion.
+
3. A GATE: COVERAGE ⊇ EXTENT, or the build breaks. Not "the check should be updated" — the build
+ BREAKS. A mechanism that grows an axis its witness does not read is a mechanism whose witness
+ is unproven, and unproven is not green.
+
4. THE WITNESS CARRIES THE EXTENT'S DIGEST. A receipt issued against the old extent is not a
+ passing receipt against the new one. It stops being GREEN and becomes UNPROVEN — a different
+ word, and today there was no such word. This is what makes the expiry automatic rather than
+ remembered: the witness invalidates itself when the world it witnessed changes shape.
+
THE INVERSION, WHICH IS THE WHOLE DECISION:
+
before → improving the mechanism BLINDS its witness, in silence
+ after → improving the mechanism BREAKS its witness, loudly
+
That is what one wants from a witness. A check that cannot notice the world changed is not a check;
+it is a certificate of a world that no longer exists, and it signs in green.
+
AND THE PUBLICATION AXIS HAS A RULE OF ITS OWN, BECAUSE IT IS THE ONE THAT LOOKS ALREADY SOLVED:
+
A CHECK VERIFIES THE TREE THAT IS SERVED, NEVER THE TREE THAT IS WRITTEN.
+
A canonical tree and a served tree that disagree is A PUBLICATION THAT DID NOT HAPPEN, and the
+disagreement is invisible to every existence check ever written, because they all ask "does the file
+exist?" — a question with a true answer in the tree nobody reads. The artifact answers 200, sits in
+the index, and is absent from the page. So the cheapest possible witness is also the one that was
+missing: COMPARE THE TWO TREES, and fail when the served one is short.
+
AND THE DISK IS ITSELF A PROXY, WHICH IS WHY THE CHAIN DOES NOT END THERE. Comparing two trees on
+disk closes a real gap, and not the last one: THE SERVER READS ITS INDEX INTO MEMORY AT STARTUP.
+After the mirror ran and both trees said five, the grid still showed four, and only a restart fixed
+it. A gate that stops at the filesystem certifies a publication no reader can see.
+
THE PAGE IS THE PUBLICATION. THE WITNESS AT THE END OF THE CHAIN ASKS: IS THE CASE ON THE PAGE?
+
And it asks it the expensive way, because the cheap way is what failed. IT COUNTS THE CARD, NOT THE
+STRING: a case's id also lives in the page's nav, its meta tags and two JSON blobs — `testigo-ciego`
+occurs FOUR TIMES before the first card ever opens — so a page-wide grep reports a case as present
+while its card is missing. That grep is not hypothetical: it is the verification that reported "5
+cards" over a grid rendering four. And ZERO CARDS IS A FINDING, NEVER AN ANSWER: a page that yields
+no card cannot be distinguished from a card the check no longer knows how to read, and both are
+findings.
+
The two questions are different and the chain must keep them apart. "Is the disk right?" is
+answerable offline, always. "Is the site right?" REQUIRES A SITE — and where there is none the
+answer is not green, it is `I DID NOT LOOK`. So the offline aggregate now ends by saying what it is
+NOT: six gates green ON DISK is not proof of publication.
+
AND THE WITNESS ITSELF IS A MECHANISM, SO IT TOO GETS THE TREATMENT. To recognise a card it must
+know the framework's markup — which is a coupling, and therefore an axis, and therefore the same
+defect one level up: re-skin the grid and the recogniser silently matches nothing. A witness that
+can only report "I found no cards" is reporting A MYSTERY, and a mystery is read as an empty grid,
+which is read as health. That is this ADR's own pathology, wearing the ADR's own uniform.
+
So the marker is DECLARED (`card`, in the surface file — never a literal in the checker), and the
+page is read TWICE, by two readings that adjudicate each other:
+
the MARKER reading knows the card class. Precise, and blinded by a re-skin.
+ the STRUCTURAL reading knows no class at all — it deletes what is not content (script, nav,
+ header, footer) and asks which case links survive. It CANNOT be re-skinned into silence,
+ because it never knew the skin.
+
When the marker finds nothing and the structure finds cases, THE PAGE IS FINE AND THE WITNESS IS
+STALE — and now it can say exactly that, name the marker, and name the file that repairs it. The
+sentence "I do not recognise what I am watching" is the third thing a check could not say, and it
+is the one a check needs most, because it is the only one that indicts the check itself.
+
WHAT A CHECK MUST BE ABLE TO SAY, AND COULD NOT. Three sentences, and the protocol had a word for
+none of them:
+
"I did not look." — a source that fails to load is a FINDING, not an empty list. One
+ check returned zero findings BECAUSE IT COULD NOT LOOK, and that
+ is the worst possible green.
+ "I cannot know this." — adr-071's `gateable` / `gate_source`. A rule a regex cannot
+ falsify must be marked uncheckable IN THE DATA, or the check
+ cries wolf and gets skipped.
+ "I am no longer complete." — THIS ADR. The extent grew and my coverage did not.
+ "I no longer recognise — THIS ADR, turned on the witness. The thing I watch was re-skinned
+ what I am watching." and I match nothing in it. Without this sentence the check reports
+ "no cards found", which is a MYSTERY — and a mystery is read as an
+ empty grid, and an empty grid is read as health. It is the only one
+ of the four that indicts the CHECK rather than the world.
+
FALSIFY AGAINST THE NEW CAPABILITY, NOT THE OLD ONE. The gate above makes forgetting impossible; it
+does not make the check CORRECT. Every one of the three blindings was caught the same way — by
+falsifying: injecting `fr` into the languages, injecting `gate → puerta` beside `door → puerta`,
+running the gate against the page just created. Where the falsification was run against the OLD
+capability, the check stayed green and lied. So the constraint is not "the check passes" but "the
+check has been SEEN TO REFUSE the new capability's failure mode".
+
AND A CHECK MEASURES THE CAPABILITY, NOT ITS PROXY. "Has a title key" is a proxy for "renders its
+content", and it is satisfiable by adding fourteen strings while the page stays empty. A gate that
+can be turned green without fixing anything is a gate that WILL be, and that is not a hypothesis:
+it is what nearly happened, and the word used at the time was "trivial".
+
+
Constraints
+
+
Hard A mechanism whose witness gates it MUST declare its EXTENT as data — the axes over which it exists (formats, levels, languages, locations, surfaces). An extent that lives only in a script is folklore, and a witness cannot be measured against folklore.
Hard A check MUST declare its COVERAGE, and a gate MUST enforce coverage ⊇ extent. Growing an axis the witness does not read MUST break the build — not warn, not log, BREAK.
Hard A check whose source fails to load MUST report a FINDING, never an empty result. Returning zero findings because you could not look is the worst available green.
Hard A check extended for a new capability MUST be SEEN TO REFUSE that capability's failure mode. Passing is not evidence; refusing is. Every oracle MUST carry a negative case per axis it covers, and the negative case MUST be COMMITTED — a falsification performed by hand and then discarded leaves the next extension exactly as unprotected as the last one.
Hard An expediente MUST exist in every language the project declares. `gen-expediente.nu --check` MUST read the declared languages and fail on a case that is missing one — and MUST be seen to refuse a language added to the extent that no case answers for.
Hard A check that verifies a publication MUST verify the SERVED tree, not the canonical one. A canonical tree and a served tree that disagree is a publication that did not happen. The check MUST be seen to REFUSE a case present in the canonical tree and absent from the served one.
Hard A publication is proven on the SERVED SURFACE, never on the filesystem. The witness MUST load the page a reader loads and assert the case is RENDERED — counting the rendered element, not an occurrence of its id in the markup. Its recogniser MUST be DECLARED as data, never a literal in the checker, and the page MUST be read a SECOND time by a reading that knows no markup — so that a re-skin is reported as a STALE WITNESS by name, and not as an empty grid. A page that cannot be fetched, a page in which neither reading finds anything, and two readings that disagree are all FINDINGS: none is an empty result and none is green.
Soft A check SHOULD measure the capability, not a proxy for it. A gate that can be turned green without fixing anything WILL be.
+
+
Alternatives considered
+
+
Write it in the howto: 'remember to extend the check when you extend the mechanism.' — rejected: Tried, this session, and disproved by the strongest possible case: the agent that broke the rule three times had AUTHORED it hours earlier, in an ADR, under its own name. If a rule cannot hold the person who wrote it, with the text still open, it holds nobody. Advisory prose is the failure mode, not the cure.
Test coverage metrics — require every check to report a percentage. — rejected: A percentage of WHAT? The denominator is the extent, and the extent is precisely what nothing declares. A coverage number computed against the files that happen to exist reports 100% while an entire language, level or format is missing — which is exactly the number `gen-expediente.nu --check` was reporting when it said '8 cases reproduce'. Without a declared denominator, a coverage metric is the disease wearing a lab coat.
Make the checks read the world dynamically — discover formats, levels and languages at runtime rather than declaring them. — rejected: This is what they already did, and it is the bug. A check that discovers its own extent from what it finds can never notice what is MISSING: it globs `*.toml`, finds no `.ncl`, and reports success. Discovery cannot distinguish 'there is nothing there' from 'I do not know how to look'. Only a declaration can, because only a declaration can be WRONG.
Verify the canonical tree and trust the sync recipe to have run. — rejected: The recipe not having run IS the defect, so trusting it is assuming the conclusion. And the trust is not idle: it was held by every check on the page, all of which passed while the case was invisible, because the tree they trusted was the one the recipe reads FROM. A witness whose validity depends on a step it does not observe is witnessing the step it can see and signing for the one it cannot.
Make the generator write straight into the served tree — delete the second tree and the problem with it. — rejected: It removes this instance and keeps the class, which is the trade this ADR exists to refuse. Two trees exist for a reason (adr-070: they are typed by OWNERSHIP — one is generated, one is assembled from several owners), and collapsing them to dodge a blind check re-creates the anti-pattern adr-070 closed. The defect was never that there were two trees; it was that the WITNESS did not know there were two. Fix the witness, not the world it failed to see.
Fail the build on any change to a mechanism until every check is re-run. — rejected: Re-running a blind check produces a blind pass. All three blindings survived every subsequent run of the check — that is what made them blindings rather than failures. What must expire is not the RUN but the PROOF, and only a witness bound to an extent can expire.
+
+
Anti-patterns
+
+
The Witness That Certified a World Which No Longer Existed — A check is written against the mechanism as it is, and it is CORRECT. Then the mechanism is EXTENDED — a new format, a new level, a new owner, a new language — and the check stays where it was. It does not fail. It does not warn. It looks where it always looked, finds nothing wrong there, and signs in green. The blinding is caused by the IMPROVEMENT, which is why it is invisible: the moment a witness is most likely to go blind is the moment you extend what it watches, and that is also the moment you are least likely to be looking at the witness. It happened three times in four hours to one witness, on three consecutive improvements, with zero warnings emitted.
Zero Findings Because the Check Could Not Look — A check's source fails to load — an export dies, a path does not resolve, a format is unknown — and the check returns an EMPTY result rather than a finding. Zero findings is then reported as clean. This is the worst available green, because it is indistinguishable from health by every downstream reader, and because the failure that produced it is often the most interesting thing on the run. The sibling defect: a RESOLVER that returns a wrong answer instead of NO answer — `.canonicalize().unwrap_or_else(|_| <the path that just failed>)` — so a missing directory travels three layers and surfaces as a bare 'IO error' and a blank page.
A Gate That Can Be Turned Green Without Fixing Anything — A check measures a PROXY for the capability instead of the capability. It asks 'does this route declare a title key?' when the thing that matters is 'does this route render its content?'. The proxy is cheap to satisfy — fourteen strings — and satisfying it turns the gate green while the real defect (304 declared Fluent keys never rendered, ten pages returning 200 over an empty body) is untouched. The tell is the word used to describe the fix: 'trivial'. A gate that can be satisfied trivially will be, and then it certifies the defect it was built to catch.
The File Exists, in the Tree No One Reads — A generator writes to a canonical tree, a server reads a served tree, and a recipe mirrors one into the other. Run the generator alone and the artifact is generated, validated, activated and INDEXED — and it is not on the page. Every existence check passes, because every one of them asks 'does the file exist?' and that question HAS A TRUE ANSWER in the tree nobody serves. Nothing is missing and nothing errors; the two trees simply hold different worlds, dated a day apart. The tell is the contradiction that looks impossible: the article answers 200, its entry is in the index, and the grid does not show it. Existence is not a property of a file — it is a property of the tree that is READ, and a check that never names which tree that is has not checked publication at all.
Writing It in the Guide and Calling It Fixed — A structural defect — one that recurs because of how the system is built, not because of how anyone behaved — is met with a documented rule: 'remember to update the check'. It reads as diligence and it changes nothing, because a rule that depends on remembering fails exactly when memory is loaded, which is exactly when the defect is created. The disproof available here is total: the agent that broke this rule three times had AUTHORED it that same afternoon, in an ADR, under its own name (`gate-green-over-nothing`), with the text open. If a rule cannot hold its own author, hours later, it holds nobody.
diff --git a/site/site/content/adr/en/accepted/adr-072.ncl b/site/site/content/adr/en/accepted/adr-072.ncl
new file mode 100644
index 0000000..b10eec2
--- /dev/null
+++ b/site/site/content/adr/en/accepted/adr-072.ncl
@@ -0,0 +1,12 @@
+{
+ id = "adr-072",
+ title = "A check declares its coverage, a mechanism declares its extent, and the witness carries the extent",
+ slug = "072",
+ excerpt = "",
+ tags = ["adr", "accepted"],
+ page_route = "/adr/072",
+ graph = {
+ implements = [],
+ related_to = ["adr-071", "adr-070", "adr-066", "adr-050"],
+ },
+}
diff --git a/site/site/content/adr/en/proposed/adr-020.md b/site/site/content/adr/en/proposed/adr-020.md
deleted file mode 100644
index b19b19d..0000000
--- a/site/site/content/adr/en/proposed/adr-020.md
+++ /dev/null
@@ -1,86 +0,0 @@
----
-id: "adr-020"
-title: "Three-Layer Model for Project Ontoref Instances"
-slug: "020"
-subtitle: "Proposed"
-excerpt: "Multiple projects now adopt the ontoref protocol (lian-build is the explicit"
-author: "ontoref"
-date: "2026-05-03"
-published: true
-featured: false
-category: "proposed"
-tags: ["adr-020", "adr", "proposed"]
-css_class: "category-adr"
----
-
Context
-
-
Multiple projects now adopt the ontoref protocol (lian-build is the explicit
-external case under bl-002 / bl-008). Field experience across ontoref +
-lian-build + provisioning shows that an ontoref-onboarded project's
-repository carries TWO distinct ontoref-shaped layers, while a third layer
-exists outside the project (in caller repositories). Without codification,
-adopters re-derive the model per project, mix layers accidentally, and lose
-boundaries silently:
-
- Layer 3 content (caller-side cabling) drifts into a project's qa.ncl,
- making the FAQ a how-to-deploy guide for one specific caller.
- - Layer 2 schemas live under reflection/ as 'project notes', drifting
- from the binary because they're not on the contract path.
- - Layer 1 architectural rationale ends up in catalog/domains/<id>/
- contract.ncl, where consumers expecting a typed shape get prose.
-
The model has been observed (lian-build/reflection/qa.ncl::lian-build-what-
-and-why), described (ontoref/reflection/qa.ncl::ontoref-three-layer-model),
-and queued for codification (bl-009). This ADR commits the model with
-machine-checkable constraints. Acceptance is gated on the constraints
-running clean across the existing ontoref-onboarded projects (ontoref
-itself, lian-build, provisioning).
-
-
Decision
-
-
A project's ontoref instance has THREE distinct layers — but only the first
-two live in the project's own repository:
-
LAYER 1 — Self-management ontoref (about the project itself)
- paths .ontology/ reflection/ adrs/
- audience this project's developers and maintainers
- purpose describe the project to itself — axioms, FSM dimensions,
- binding decisions, open questions, accepted knowledge
- presence MANDATORY on every ontoref-onboarded project
-
LAYER 2 — Specialized domain/mode ontoref (the integration surface)
- paths schemas/ catalog/{domains,modes}/
- manifest.ncl::registry_provides
- audience OTHER projects that want to integrate this project
- purpose the contract surface other projects bind to — typed domain
- artifacts, orchestration mode artifacts, registry-namespace
- claim
- presence OPTIONAL but BICONDITIONAL — a project either has all of
- {schemas/, catalog/, registry_provides} or none. Half-Layer-2
- is a contract violation.
-
LAYER 3 — Caller-side implementations (NOT in this project)
- paths <caller>/extensions/<this-project>/
- <caller>/catalog/components/<...>/ (when consuming)
- <workspace>/infra/<ws>/integrations/
- audience operators and CI of caller projects
- presence PER CALLER, NEVER in this project's repo. Cross-references
- from this project to Layer 3 are explicit pointers, never
- copy-paste.
-
The three-layer axis is ORTHOGONAL to ADR-018's level hierarchy
-(Base/Domain/Instance). A project at any level may have any combination of
-Layer 1 (always) and Layer 2 (sometimes). Layer 3 is the boundary outward,
-not a property of the project. The 3-layer × 3-level matrix is navigable in
-both axes: 'where in the protocol hierarchy' (level) is independent of
-'where in the project's repo' (layer).
-
Cross-layer references inside a project carry an explicit layer-N tag on
-qa entries. A qa entry whose primary topic is a Layer N concern wears
-the layer-N tag; satellite entries (operational how-to, troubleshooting)
-inherit the layer of their anchor without re-tagging.
-
-
Constraints
-
-
Hard Every ontoref-onboarded project has .ontology/core.ncl
Hard Every ontoref-onboarded project has reflection/qa.ncl
Hard Every ontoref-onboarded project has reflection/backlog.ncl
Hard Every ontoref-onboarded project has an adrs/ directory
Hard A federated-peer catalog (catalog/domains/ or catalog/modes/) exists if and only if manifest.ncl declares registry_provides
Soft qa entries whose primary topic is a Layer N concern carry the layer-N tag (anchors only; satellites inherit by association)
-
-
Alternatives considered
-
-
Single 'ontoref content' namespace, no layering — rejected: Observed drift outcomes (Layer 3 in qa, Layer 2 schemas treated as notes, etc.) are caused precisely by absence of layering. The single-namespace alternative is what we're correcting; rejecting it is the entire decision.
Two-layer model collapsing self-management with integration-surface — rejected: lian-build's adoption explicitly experienced the schema-vs-rationale split: schemas/build_directives.ncl (Layer 2 contract) and adrs/adr-001-lian-build-as-standalone.ncl (Layer 1 rationale) have different audiences, different change cadences, different validation rules. Collapsing them produced the FAQ-vs-contract confusion that retiring lian-build/.ontology/FAQ.md addressed. The two-layer alternative re-creates that confusion.
Make Layer 3 (caller-side) optionally co-resident with Layer 2 in the producer's repo — rejected: Creates ambiguity about who owns the cabling. If a producer's repo carries `extensions/<self>/`, who maintains it when a caller's workspace evolves? The producer doesn't know about the caller's infrastructure; the caller can't depend on the producer to update the cabling on its schedule. Co-residence inverts the integration arrow.
Numbered layers (Layer 1 / 2 / 3) vs named layers ('self' / 'integration-surface' / 'caller-side') — rejected: Named layers are more descriptive but verbose; numbered layers are more precise but flat. The compromise (this ADR): use 'Layer N — descriptive name' in prose, 'layer-N' in tags. Tag economy wins; prose retains the descriptive name.
diff --git a/site/site/content/adr/en/proposed/adr-020.ncl b/site/site/content/adr/en/proposed/adr-020.ncl
deleted file mode 100644
index 50fd349..0000000
--- a/site/site/content/adr/en/proposed/adr-020.ncl
+++ /dev/null
@@ -1,12 +0,0 @@
-{
- id = "adr-020",
- title = "Three-Layer Model for Project Ontoref Instances",
- slug = "020",
- excerpt = "",
- tags = ["adr", "proposed"],
- page_route = "/adr/020",
- graph = {
- implements = [],
- related_to = ["adr-001", "adr-016", "adr-018"],
- },
-}
diff --git a/site/site/content/blog/en/engineering/release-engineering-from-one-model.md b/site/site/content/blog/en/engineering/release-engineering-from-one-model.md
index 4f157bd..5bb0786 100644
--- a/site/site/content/blog/en/engineering/release-engineering-from-one-model.md
+++ b/site/site/content/blog/en/engineering/release-engineering-from-one-model.md
@@ -19,6 +19,7 @@ tags: ["release-engineering", "ci", "oci", "nickel", "supply-chain", "rust"]
# Image (card thumbnail + in-post featured)
thumbnail: "/images/ontoref-release-one-model-post.webp"
image_url: "/images/ontoref-release-one-model-post.webp"
+og_image: "/images/og/ontoref-release-one-model-post.png"
# Display
read_time: "8 min read"
diff --git a/site/site/content/blog/en/ontoref/ai-knowledge-tool-who-keeps-it-alive.md b/site/site/content/blog/en/ontoref/ai-knowledge-tool-who-keeps-it-alive.md
index 9bc302b..3ab8b06 100644
--- a/site/site/content/blog/en/ontoref/ai-knowledge-tool-who-keeps-it-alive.md
+++ b/site/site/content/blog/en/ontoref/ai-knowledge-tool-who-keeps-it-alive.md
@@ -19,6 +19,7 @@ tags: ["ontoref", "knowledge-graphs", "ontology", "ai-infrastructure", "reflecti
# Image (card thumbnail + in-post featured)
thumbnail: "/images/ontoref-ai-knowledge-post.webp"
image_url: "/images/ontoref-ai-knowledge-post.webp"
+og_image: "/images/og/ontoref-ai-knowledge-post.png"
# Display
read_time: "7 min read"
diff --git a/site/site/content/blog/en/ontoref/context-declared-not-filled.md b/site/site/content/blog/en/ontoref/context-declared-not-filled.md
index bf4e85c..d1efe08 100644
--- a/site/site/content/blog/en/ontoref/context-declared-not-filled.md
+++ b/site/site/content/blog/en/ontoref/context-declared-not-filled.md
@@ -18,6 +18,7 @@ tags: ["ontoref", "context-engineering", "library-science", "warrant", "knowledg
# Image (card thumbnail + in-post featured)
thumbnail: "/images/ontoref-context-declared-not-filled.webp"
+og_image: "/images/og/ontoref-context-declared-not-filled.png"
---
diff --git a/site/site/content/blog/en/ontoref/dags-everywhere-none-know-what-they-are.md b/site/site/content/blog/en/ontoref/dags-everywhere-none-know-what-they-are.md
index 3536401..6c1e160 100644
--- a/site/site/content/blog/en/ontoref/dags-everywhere-none-know-what-they-are.md
+++ b/site/site/content/blog/en/ontoref/dags-everywhere-none-know-what-they-are.md
@@ -19,6 +19,7 @@ tags: ["ontoref", "dag", "ontology", "knowledge-graphs", "software-architecture"
# Image (card thumbnail + in-post featured)
thumbnail: "/images/ontoref-dags-everywhere_post.webp"
image_url: "/images/ontoref-dags-everywhere_post.webp"
+og_image: "/images/og/ontoref-dags-everywhere_post.png"
# Display
read_time: "6 min read"
diff --git a/site/site/content/blog/en/ontoref/one-protocol-multiple-subjects.md b/site/site/content/blog/en/ontoref/one-protocol-multiple-subjects.md
index 86840fc..5320804 100644
--- a/site/site/content/blog/en/ontoref/one-protocol-multiple-subjects.md
+++ b/site/site/content/blog/en/ontoref/one-protocol-multiple-subjects.md
@@ -25,6 +25,7 @@ category_published: true
# Image (card thumbnail + in-post featured)
thumbnail: "/images/ontoref-one-protocol-multiple-subjects.webp"
+og_image: "/images/og/ontoref-one-protocol-multiple-subjects.png"
---
diff --git a/site/site/content/blog/en/ontoref/the-seven-sins-of-ai-agents.md b/site/site/content/blog/en/ontoref/the-seven-sins-of-ai-agents.md
index 4a52b10..395549a 100644
--- a/site/site/content/blog/en/ontoref/the-seven-sins-of-ai-agents.md
+++ b/site/site/content/blog/en/ontoref/the-seven-sins-of-ai-agents.md
@@ -19,6 +19,7 @@ tags: ["ontoref", "ai-agents", "verification", "adr", "governance", "pep-kep"]
# Image (card thumbnail + social/feature)
thumbnail: "/images/ontoref-seven-sins-post.webp"
image_url: "/images/ontoref-seven-sins-post.webp"
+og_image: "/images/og/ontoref-seven-sins-post.png"
# Display
read_time: "6 min read"
diff --git a/site/site/content/blog/en/ontoref/trust-is-an-output-not-an-input.md b/site/site/content/blog/en/ontoref/trust-is-an-output-not-an-input.md
index 8b495a0..0cbe4fb 100644
--- a/site/site/content/blog/en/ontoref/trust-is-an-output-not-an-input.md
+++ b/site/site/content/blog/en/ontoref/trust-is-an-output-not-an-input.md
@@ -19,6 +19,7 @@ tags: ["ontoref", "ai-agents", "governance", "verification", "witness", "work-or
# Image (card thumbnail + social/feature)
thumbnail: "/images/ontoref-trust-output-post.webp"
image_url: "/images/ontoref-trust-output-post.webp"
+og_image: "/images/og/ontoref-trust-output-post.png"
# Display
read_time: "7 min read"
diff --git a/site/site/content/blog/en/ontoref/your-ontology-should-live-with-your-code.md b/site/site/content/blog/en/ontoref/your-ontology-should-live-with-your-code.md
index 447fc85..a620f57 100644
--- a/site/site/content/blog/en/ontoref/your-ontology-should-live-with-your-code.md
+++ b/site/site/content/blog/en/ontoref/your-ontology-should-live-with-your-code.md
@@ -19,6 +19,7 @@ tags: ["ontoref", "sovereignty", "federation", "radicle", "jujutsu", "knowledge-
# Image (card thumbnail + in-post featured)
thumbnail: "/images/ontology-live-with-code-post.webp"
image_url: "/images/ontology-live-with-code-post.webp"
+og_image: "/images/og/ontology-live-with-code-post.png"
# Display
read_time: "6 min read"
diff --git a/site/site/content/blog/es/engineering/release-engineering-from-one-model.md b/site/site/content/blog/es/engineering/release-engineering-from-one-model.md
index 1b1c234..fbdad01 100644
--- a/site/site/content/blog/es/engineering/release-engineering-from-one-model.md
+++ b/site/site/content/blog/es/engineering/release-engineering-from-one-model.md
@@ -19,6 +19,7 @@ tags: ["release-engineering", "ci", "oci", "nickel", "supply-chain", "rust"]
# Image (card thumbnail + in-post featured)
thumbnail: "/images/ontoref-release-one-model-post.webp"
image_url: "/images/ontoref-release-one-model-post.webp"
+og_image: "/images/og/ontoref-release-one-model-post.png"
# Display
read_time: "8 min de lectura"
@@ -56,7 +57,7 @@ La superficie de release vive en un único modelo NCL de flujo de trabajo
- `OnCommit` — hooks de pre-commit
- `OnPR` — comprobaciones por pull request
-- `OnMainMerge` — integración al hacer merge a main
+- `OnMainMerge` — integración al fusionar en main
- `OnTag` — la capa de release
Dentro de esas capas, el trabajo es tipado. Los build kinds llevan `'Bundle` y
@@ -130,7 +131,7 @@ runner.
Esto es más barato y determinista: un índice multi-arch construido desde binarios
por-arch ya compilados, no ejecutando un builder amd64 bajo emulación arm64. Y es
-un *constraint*, no una convención — el modelo prohíbe recompilar por arch para
+una *restricción*, no una convención — el modelo prohíbe recompilar por arch para
construir la imagen, así que un futuro contribuidor que tire del familiar
`docker buildx --platform` queda frenado por el modelo en vez de publicar
silenciosamente un binario divergente.
@@ -151,7 +152,7 @@ dependencia de *ejecución* — y `Protocolo, no Runtime` es un axioma invariant
modelo hace explícita la resolución en vez de confiar en ella. El instalador
`curl|sh` instala un CLI + capa de datos que funcionan **sin** el daemon (ADR-029:
el daemon es una caché, no una dependencia dura); la imagen ejecutable es un
-**acelerador opcional** para despliegues en contenedor. Un constraint tipado —
+**acelerador opcional** para despliegues en contenedor. Una restricción tipada —
`daemon-image-optional-not-runtime` — vigila que un cambio futuro no pueda hacer el
daemon obligatorio sin avisar.
diff --git a/site/site/content/blog/es/ontoref/ai-knowledge-tool-who-keeps-it-alive.md b/site/site/content/blog/es/ontoref/ai-knowledge-tool-who-keeps-it-alive.md
index 96d18b2..1651799 100644
--- a/site/site/content/blog/es/ontoref/ai-knowledge-tool-who-keeps-it-alive.md
+++ b/site/site/content/blog/es/ontoref/ai-knowledge-tool-who-keeps-it-alive.md
@@ -19,6 +19,7 @@ tags: ["ontoref", "knowledge-graphs", "ontology", "ai-infrastructure", "reflecti
# Image (card thumbnail + in-post featured)
thumbnail: "/images/ontoref-ai-knowledge-post.webp"
image_url: "/images/ontoref-ai-knowledge-post.webp"
+og_image: "/images/og/ontoref-ai-knowledge-post.png"
# Display
read_time: "7 min read"
@@ -56,7 +57,7 @@ El sexto paso en su stack es "Govern — esto es infraestructura, stewardship, v
La pregunta real es: *¿quién asegura que la ontología no derive respecto al sistema que describe?*
-El software evoluciona. Una decisión arquitectónica tomada en marzo invalida un nodo del grafo en octubre. Se incorpora un nuevo equipo con modelos mentales distintos. Una librería se reemplaza y un constraint se convierte en ficción. Los knowledge graphs acumulan deuda igual que los codebases — silenciosamente, sin alarmas.
+El software evoluciona. Una decisión arquitectónica tomada en marzo invalida un nodo del grafo en octubre. Se incorpora un nuevo equipo con modelos mentales distintos. Una biblioteca se reemplaza y una restricción se convierte en ficción. Los knowledge graphs acumulan deuda igual que los codebases — silenciosamente, sin alarmas.
En el mundo enterprise de knowledge graphs, la respuesta al governance es headcount: contratar ontólogos, bibliotecarios, knowledge engineers. Funciona a escala organizacional con presupuestos dedicados. No es una respuesta viable para un proyecto de software, un entorno de infraestructura, o un individuo que intenta mantener auto-conocimiento estructurado.
@@ -80,13 +81,14 @@ Este es el Yang al Yin de la ontología. Talisman describe el Yin con precisión
**Ontología (lo que ES):** nodos y aristas tipadas que representan prácticas, principios, tensiones, capacidades. No documentación — compromisos formales. Un nodo `Practice` que `implements` un `Principle`, `enforces` un `Constraint`, `enables` una `Capability`, y está en `tension` activa con otra `Practice`. El proyecto como knowledge graph.
-**Reflection (lo que DEVIENE):** DAGs ejecutables — modos operacionales que corren contra el estado ontológico, detectan deriva, registran transiciones y propagan cambios. El comando `sync diff --docs` que detecta cuándo la documentación de un crate ha derivado de su nodo ontológico. La máquina de estados en `state.ncl` que registra dónde está cada dimensión del proyecto versus adónde pretende ir. El sistema de migraciones que asegura que los cambios de protocolo lleguen a cada proyecto consumidor.
+**Reflexión (lo que DEVIENE):** DAGs ejecutables — modos operacionales que corren contra el estado ontológico, detectan deriva, registran transiciones y propagan cambios. El comando `sync diff --docs` que detecta cuándo la documentación de un crate ha derivado de su nodo ontológico. La máquina de estados en `state.ncl` que registra dónde está cada dimensión del proyecto versus adónde pretende ir. El sistema de migraciones que asegura que los cambios de protocolo lleguen a cada proyecto consumidor.
La tensión entre estas dos capas no es un defecto de diseño — está nombrada explícitamente en la ontología del propio proyecto como su identidad central:
+
> *"Ontology captures what IS. Reflection captures what BECOMES. Both must coexist without one dominating."*
-Sin Reflection, la Ontología cristaliza. Se convierte en una fotografía de lo que el proyecto quería ser en el momento en que se escribió. Sin Ontología, Reflection es ejecución sin verdad — sabe cómo operar pero no sobre qué opera.
+Sin Reflexión, la Ontología cristaliza. Se convierte en una fotografía de lo que el proyecto quería ser en el momento en que se escribió. Sin Ontología, Reflexión es ejecución sin verdad — sabe cómo operar pero no sobre qué opera.
## Los números de precisión
@@ -96,11 +98,11 @@ Los datos de Talisman sobre lo que el conocimiento estructurado hace a la precis
- GraphRAG vs. vector RAG: **3.4× precisión** en 43 queries enterprise (Diffbot KG-LM Benchmark, 2023)
- Vector RAG colapsa a **0% precisión más allá de cinco entidades por query**. El retrieval anclado en KG sostiene el rendimiento mucho más allá
-La brecha de precisión no se cierra con un modelo más grande. Se cierra con un schema definido, una ontología, y una query validada.
+La brecha de precisión no se cierra con un modelo más grande. Se cierra con un esquema definido, una ontología, y una query validada.
Pero solo si la ontología se mantiene viva. Solo si algo o alguien ejecuta el loop operacional que evita que derive hacia la ficción.
-Esa es la parte que el framework de Talisman no provee. Para eso existe Reflection.
+Esa es la parte que el framework de Talisman no provee. Para eso existe Reflexión.
---
diff --git a/site/site/content/blog/es/ontoref/context-declared-not-filled.md b/site/site/content/blog/es/ontoref/context-declared-not-filled.md
index 6a8a533..e85e284 100644
--- a/site/site/content/blog/es/ontoref/context-declared-not-filled.md
+++ b/site/site/content/blog/es/ontoref/context-declared-not-filled.md
@@ -18,6 +18,7 @@ tags: ["ontoref", "context-engineering", "library-science", "warrant", "knowledg
# Image (card thumbnail + in-post featured)
thumbnail: "/images/ontoref-context-declared-not-filled-es.webp"
+og_image: "/images/og/ontoref-context-declared-not-filled-es.png"
---
@@ -65,7 +66,7 @@ costura del testigo existe para rechazar.
## Convergencia, campo a campo
-El detalle incómodo y satisfactorio: ontoref nunca citó Z39.19. El schema de términos del
+El detalle incómodo y satisfactorio: ontoref nunca citó Z39.19. El esquema de términos del
glosario se diseñó desde las necesidades del propio protocolo — y convergió con el estándar
casi campo a campo.
diff --git a/site/site/content/blog/es/ontoref/dags-everywhere-none-know-what-they-are.md b/site/site/content/blog/es/ontoref/dags-everywhere-none-know-what-they-are.md
index 15faf9e..265f9ff 100644
--- a/site/site/content/blog/es/ontoref/dags-everywhere-none-know-what-they-are.md
+++ b/site/site/content/blog/es/ontoref/dags-everywhere-none-know-what-they-are.md
@@ -19,6 +19,7 @@ tags: ["ontoref", "dag", "ontology", "knowledge-graphs", "arquitectura-software"
# Image (card thumbnail + in-post featured)
thumbnail: "/images/ontoref-dags-everywhere_post.webp"
image_url: "/images/ontoref-dags-everywhere_post.webp"
+og_image: "/images/og/ontoref-dags-everywhere_post.png"
# Display
read_time: "6 min read"
@@ -98,7 +99,7 @@ Tres cosas tuvieron que alinearse:
**Los agentes como consumidores.** Antes de la IA agéntica, no había ningún consumidor automatizado que necesitara conocimiento estructurado sobre un proyecto. Los humanos podían leer el wiki. Los agentes no pueden — necesitan conocimiento del proyecto tipado, consultable y machine-readable para trabajar con precisión en lugar de alucinar contexto. El DAG de conocimiento de ontoref es lo que los agentes consumen vía MCP.
-**Lenguajes de configuración con contratos.** Expresar una ontología sin un triplestore externo requería un lenguaje de configuración con tipos y contratos. Nickel (NCL) provee exactamente eso: un lenguaje de configuración tipado y lazy donde las violaciones de schema se detectan en tiempo de evaluación, no en tiempo de ejecución. RDF/OWL habría requerido infraestructura dedicada y expertise especializado.
+**Lenguajes de configuración con contratos.** Expresar una ontología sin un triplestore externo requería un lenguaje de configuración con tipos y contratos. Nickel (NCL) provee exactamente eso: un lenguaje de configuración tipado y lazy donde las violaciones de esquema se detectan en tiempo de evaluación, no en tiempo de ejecución. RDF/OWL habría requerido infraestructura dedicada y expertise especializado.
**Escala de repositorio, no de empresa.** Los knowledge graphs enterprise son iniciativas de varios años. Ontoref opera a la escala de un repositorio único — adopción incremental, sin enforcement, sin equipo dedicado. La unidad más pequeña que puede adoptarlo es un proyecto de uno.
diff --git a/site/site/content/blog/es/ontoref/one-protocol-multiple-subjects.md b/site/site/content/blog/es/ontoref/one-protocol-multiple-subjects.md
index ef61360..412bee4 100644
--- a/site/site/content/blog/es/ontoref/one-protocol-multiple-subjects.md
+++ b/site/site/content/blog/es/ontoref/one-protocol-multiple-subjects.md
@@ -25,6 +25,7 @@ category_published: true
# Image (card thumbnail + in-post featured)
thumbnail: "/images/ontoref-one-protocol-multiple-subjects-es.webp"
+og_image: "/images/og/ontoref-one-protocol-multiple-subjects-es.png"
---
diff --git a/site/site/content/blog/es/ontoref/the-seven-sins-of-ai-agents.md b/site/site/content/blog/es/ontoref/the-seven-sins-of-ai-agents.md
index fe56324..ae97ae6 100644
--- a/site/site/content/blog/es/ontoref/the-seven-sins-of-ai-agents.md
+++ b/site/site/content/blog/es/ontoref/the-seven-sins-of-ai-agents.md
@@ -19,6 +19,7 @@ tags: ["ontoref", "agentes-ia", "verificacion", "adr", "gobernanza", "pep-kep"]
# Image (card thumbnail + social/feature)
thumbnail: "/images/ontoref-seven-sins-post-es.webp"
image_url: "/images/ontoref-seven-sins-post-es.webp"
+og_image: "/images/og/ontoref-seven-sins-post-es.png"
# Display
read_time: "6 min de lectura"
@@ -77,7 +78,7 @@ solos**:
llega a `Accepted` si no está citado por una *Proof* del posicionamiento. La
graduación exige evidencia **referencial**, comprobable por máquina, no la palabra
de nadie.
-- **Contra el pecado #1 (validación soberbia).** Las *constraints* de cada ADR no son
+- **Contra el pecado #1 (validación soberbia).** Las *restricciones* de cada ADR no son
prosa: son checks tipados —`Grep`, `Cargo`, `NuCmd`, `ApiCall`, `FileExists`— que el
modo `validate-project` dispara y que **fallan en rojo** si la realidad se desvía. No
puedes ajustar el test a la solución: el test *es* la solución declarada.
@@ -97,7 +98,7 @@ solos**:
| Alternativas rechazadas obligatorias | sí | sí | sí (`alternatives_considered`, *required*) |
| Graduación por criterio pre-declarado | no | sí (humano) | **sí, witnessed y decidible** |
| Criterio acotado y verificable por máquina | no | no | **sí (slice + decidibilidad)** |
-| Constraints ejecutables, no prosa | no | no | **sí (5 variantes tipadas)** |
+| Restricciones ejecutables, no prosa | no | no | **sí (5 variantes tipadas)** |
| Cruce con invariantes del dominio | no | no | **sí (ondaod / `ontology_check`)** |
PEP y KEP son estándares maduros, y ontoref hereda lo mejor de ambos. Pero cierra el
diff --git a/site/site/content/blog/es/ontoref/trust-is-an-output-not-an-input.md b/site/site/content/blog/es/ontoref/trust-is-an-output-not-an-input.md
index d75c702..b348c29 100644
--- a/site/site/content/blog/es/ontoref/trust-is-an-output-not-an-input.md
+++ b/site/site/content/blog/es/ontoref/trust-is-an-output-not-an-input.md
@@ -19,6 +19,7 @@ tags: ["ontoref", "agentes-ia", "gobernanza", "verificacion", "testigo", "orden-
# Image (card thumbnail + social/feature)
thumbnail: "/images/ontoref-trust-output-post.webp"
image_url: "/images/ontoref-trust-output-post.webp"
+og_image: "/images/og/ontoref-trust-output-post.png"
# Display
read_time: "7 min de lectura"
diff --git a/site/site/content/blog/es/ontoref/your-ontology-should-live-with-your-code.md b/site/site/content/blog/es/ontoref/your-ontology-should-live-with-your-code.md
index 4eb2e8e..faf1aa5 100644
--- a/site/site/content/blog/es/ontoref/your-ontology-should-live-with-your-code.md
+++ b/site/site/content/blog/es/ontoref/your-ontology-should-live-with-your-code.md
@@ -19,6 +19,7 @@ tags: ["ontoref", "soberania", "federacion", "radicle", "jujutsu", "infraestruct
# Image (card thumbnail + in-post featured)
thumbnail: "/images/ontology-live-with-code-post.webp"
image_url: "/images/ontology-live-with-code-post.webp"
+og_image: "/images/og/ontology-live-with-code-post.png"
# Display
read_time: "6 min read"
diff --git a/site/site/content/domains/_spine/home-es.md b/site/site/content/domains/_spine/home-es.md
index 6521ce9..21c30e0 100644
--- a/site/site/content/domains/_spine/home-es.md
+++ b/site/site/content/domains/_spine/home-es.md
@@ -1,5 +1,5 @@
-# Pisa firme y anda ligero.
+# Pisa firme, con paso ligero.
> Tu proyecto, tu infra, tu obra, tu vida: ¿sigues yendo a donde dijiste?
diff --git a/site/site/content/domains/en/use-cases/door-authoring.md b/site/site/content/domains/en/use-cases/door-authoring.md
index 79f666a..79dd03e 100644
--- a/site/site/content/domains/en/use-cases/door-authoring.md
+++ b/site/site/content/domains/en/use-cases/door-authoring.md
@@ -17,12 +17,6 @@ category_description: "Use cases and implementations of ontoref"
category_published: true
---
-
-
-
-
-
-
**Author your Work once and diffuse it everywhere without it fragmenting. A Work — a book as archetype — is modeled as a coherent authored whole (a Central work with Satellites and Elements) carrying six typed content types; the same source projects to print, digital, web, interactive and an AI-queryable surface (RAG/MCP). Dissemination is an expression of the Work across channels, never a re-authoring per channel — so the Work stays coherent everywhere it appears.**
An authored Work lives as source files (Pages, ODT, Markdown). Each medium —
diff --git a/site/site/content/domains/en/use-cases/door-developer.md b/site/site/content/domains/en/use-cases/door-developer.md
index 96cc2bb..21b8700 100644
--- a/site/site/content/domains/en/use-cases/door-developer.md
+++ b/site/site/content/domains/en/use-cases/door-developer.md
@@ -17,12 +17,6 @@ category_description: "Use cases and implementations of ontoref"
category_published: true
---
-
-
-
-
-
-
> **AI writes faster and breaks more: +861% churn, ×3.4 incidents per PR, 31.3% of PRs merged without a single review. Team maturity does not protect you.**
>
> — [Faros · AI Engineering Report 2026 — The Acceleration Whiplash](https://www.faros.ai/blog/ai-acceleration-whiplash-takeaways) · [See what breaks](/blog?tag=developer)
diff --git a/site/site/content/domains/en/use-cases/door-infrastructure.md b/site/site/content/domains/en/use-cases/door-infrastructure.md
index 2ac660b..2fa5b73 100644
--- a/site/site/content/domains/en/use-cases/door-infrastructure.md
+++ b/site/site/content/domains/en/use-cases/door-infrastructure.md
@@ -17,12 +17,6 @@ category_description: "Use cases and implementations of ontoref"
category_published: true
---
-
-
-
-
-
-
**Your infrastructure tells you where it is on its own trajectory — not just whether resources match. `describe state` returns each dimension's current → desired with the blocker and catalyst between them; `describe connections` maps how one action depends on the next. The infra is structured as a DAG that carries sense, journey, and perspective, with declared actions that reproduce — so HA and resilience rise to another plane: a property of a system that knows its own state and how it got there, not redundancy bolted on.**
The operator who inherits infrastructure cannot see its trajectory.
diff --git a/site/site/content/domains/en/use-cases/door-personal.md b/site/site/content/domains/en/use-cases/door-personal.md
index 5ebaf7d..a614602 100644
--- a/site/site/content/domains/en/use-cases/door-personal.md
+++ b/site/site/content/domains/en/use-cases/door-personal.md
@@ -17,12 +17,6 @@ category_description: "Use cases and implementations of ontoref"
category_published: true
---
-
-
-
-
-
-
**See where your effort drifts from your intent. Model your career and commitments as a graph with a declared desired state; `describe state` shows current → desired and what blocks the next step, and the graph surfaces which commitments move you toward where you said you want to go — and which are accidental. Your own trajectory becomes queryable: what have I done, what connects, what should I do next — answered, not felt. You don't end up where you didn't choose.**
A person's career, content, decisions, and intentions live as scattered
diff --git a/site/site/content/domains/es/use-cases/door-authoring.md b/site/site/content/domains/es/use-cases/door-authoring.md
index c990e94..3f49e25 100644
--- a/site/site/content/domains/es/use-cases/door-authoring.md
+++ b/site/site/content/domains/es/use-cases/door-authoring.md
@@ -17,12 +17,6 @@ category_description: "Casos de uso e implementaciones de ontoref"
category_published: true
---
-
-
-
-
-
-
**Author your Work once and diffuse it everywhere without it fragmenting. A Work — a book as archetype — is modeled as a coherent authored whole (a Central work with Satellites and Elements) carrying six typed content types; the same source projects to print, digital, web, interactive and an AI-queryable surface (RAG/MCP). Dissemination is an expression of the Work across channels, never a re-authoring per channel — so the Work stays coherent everywhere it appears.**
An authored Work lives as source files (Pages, ODT, Markdown). Each medium —
diff --git a/site/site/content/domains/es/use-cases/door-developer.md b/site/site/content/domains/es/use-cases/door-developer.md
index 9a1211b..8e55f0f 100644
--- a/site/site/content/domains/es/use-cases/door-developer.md
+++ b/site/site/content/domains/es/use-cases/door-developer.md
@@ -17,12 +17,6 @@ category_description: "Casos de uso e implementaciones de ontoref"
category_published: true
---
-
-
-
-
-
-
> **El AI escribe más rápido y rompe más: +861% de churn, ×3.4 incidentes por PR, 31.3% de PRs fusionados sin una sola revisión. La madurez del equipo no protege.**
>
> — [Faros · AI Engineering Report 2026 — The Acceleration Whiplash](https://www.faros.ai/blog/ai-acceleration-whiplash-takeaways) · [Comprueba qué se rompe](/blog?tag=developer)
diff --git a/site/site/content/domains/es/use-cases/door-infrastructure.md b/site/site/content/domains/es/use-cases/door-infrastructure.md
index 36d5f32..084e5f1 100644
--- a/site/site/content/domains/es/use-cases/door-infrastructure.md
+++ b/site/site/content/domains/es/use-cases/door-infrastructure.md
@@ -17,12 +17,6 @@ category_description: "Casos de uso e implementaciones de ontoref"
category_published: true
---
-
-
-
-
-
-
**Your infrastructure tells you where it is on its own trajectory — not just whether resources match. `describe state` returns each dimension's current → desired with the blocker and catalyst between them; `describe connections` maps how one action depends on the next. The infra is structured as a DAG that carries sense, journey, and perspective, with declared actions that reproduce — so HA and resilience rise to another plane: a property of a system that knows its own state and how it got there, not redundancy bolted on.**
The operator who inherits infrastructure cannot see its trajectory.
diff --git a/site/site/content/domains/es/use-cases/door-personal.md b/site/site/content/domains/es/use-cases/door-personal.md
index 034bf98..7ba3dd1 100644
--- a/site/site/content/domains/es/use-cases/door-personal.md
+++ b/site/site/content/domains/es/use-cases/door-personal.md
@@ -17,12 +17,6 @@ category_description: "Casos de uso e implementaciones de ontoref"
category_published: true
---
-
-
-
-
-
-
**See where your effort drifts from your intent. Model your career and commitments as a graph with a declared desired state; `describe state` shows current → desired and what blocks the next step, and the graph surfaces which commitments move you toward where you said you want to go — and which are accidental. Your own trajectory becomes queryable: what have I done, what connects, what should I do next — answered, not felt. You don't end up where you didn't choose.**
A person's career, content, decisions, and intentions live as scattered
diff --git a/site/site/content/resources/en/decks/ai-infra.md b/site/site/content/resources/en/decks/ai-infra.md
new file mode 100644
index 0000000..b48d476
--- /dev/null
+++ b/site/site/content/resources/en/decks/ai-infra.md
@@ -0,0 +1,169 @@
+---
+id: "ai-infra"
+title: "Does AI manage your infra?"
+slug: "does-ai-manage-your-infra"
+subtitle: ""
+excerpt: ""
+
+author: "Jesús Pérez"
+date: "2026-07-15"
+published: true
+featured: false
+
+category: "decks"
+tags: ["ontoref", "slides"]
+
+# Card + share image. The webp carousel is no longer the CONTENT — the slides carry real text
+# now — but slide 0 still makes the best thumbnail.
+thumbnail: "/images/decks/ai-infra/thumb-en.webp"
+image_url: "/images/decks/ai-infra/thumb-en.webp"
+og_image: "/images/og/decks-ai-infra-thumb-en.png"
+
+sort_order: 1
+---
+
+
+
+
+
+
+
+
+
+
+
+ 1 / 12
+
+
+
+
+
+
+
+
+
AI manages your infra... Do you know what's happening?
Ontology and Reflection as the ground of a project that understands itself.
The problem is not the tool
What AI does well
✓
Generates syntactically correct YAML
✓
Completes Terraform that never breaks the plan
✓
Fills configuration gaps with reasonable defaults
✓
Translates intent into declarative form
What AI cannot do
✗
Know why that service cannot scale to N replicas
✗
Know the tension between latency and consistency in your system
✗
Remember the decision you made in December and why you rejected the alternative
✗
Understand what cannot break without cross-team coordination
Declarative ≠ understanding. You describe the desired state, not the why.
2am — when Terraform won’t talk
What you see when it fails
Error: Error creating Instance:
+ googleapi: Error 400: Invalid value
+ for field 'resource.machineType'
+
+# The plan passed. The apply failed.
+# What did the agent assume?
+# Which region did it pick? Why that type?
+# Is there an org constraint it never knew?
# What the AI generated (6 weeks ago)
+resource "google_compute_instance" "api" {
+ machine_type = "e2-medium" # "reasonable"
+ zone = "us-central1-a" # "default"
+}
+
+# What your org policy requires
+# → only europe-west1, only n2-standard-*
+# → the AI didn't know because you never wrote it down either
The pattern that repeats
With no explicit model
The AI invents plausible context. You assume it knows. It fails in prod.
With Stack Overflow
You copy code without understanding the assumption. At least you went looking.
With the AI
The agent generates with confidence. Confidence is contagious. So is the error.
The difference from Stack Overflow: At least there you were actively searching. With the AI, you delegate the search too.
Your project lives in your head
What lives only in your head
→
Why this service cannot have more than 3 replicas
→
What happened when we tried to scale in January, and why we failed
→
The tension between the platform team and the product team over who controls networking
→
Which alternative was rejected, and why
→
Which invariant cannot be violated without breaking the agreement with the security team
What lives only in your head cannot be validated. An agent cannot consult it. A new teammate cannot consult it. You cannot consult it yourself in 6 months.
The README trap
# My Project
+
+This service does X. It is deployed on GCP.
+It uses Terraform. It has 3 environments: dev, staging, prod.
+
+## Architecture
+See diagram (out of date since March).
+
+## Decisions
+- We chose PostgreSQL because we didn't like MySQL.
+- We use gRPC internally.
✗
It doesn't say what cannot change
✗
It captures neither the rejected alternatives nor the why
✗
It is not queryable or verifiable — it is prose
✗
It does not reflect the current state — it reflects the state when it was written
The thesis
The ontology is not for the AI.
It is for you.
Formalizing invariants, tensions and current state forces you to know what is true right now.
The AI benefits as a side effect. It operates on what you already made clear.
The real value: the act of writing the ontology is where YOU get clear, not the AI.
Ontology ≠ a list of decisions
A list of decisions
- We chose Kubernetes
+- We use Helm for deployments
+- PostgreSQL as the primary database
+- gRPC between internal services
+- OAuth2 for external authentication
Captures the what. It captures neither the why, the rejected alternatives, nor the consequences.
An ontology
INVARIANTS
What cannot change without an explicit decision and coordination
ACTIVE TENSIONS
Trade-offs not yet resolved — they live in the system right now
CURRENT → DESIRED STATE
Maturity dimensions. Where you are, where you want to be, what blocks you
ACTIVE GATES
Conditions that must hold before crossing an architectural boundary
It is a queryable graph. Not prose. The AI can read it. Your CI can verify it. You can reason about it.
Typed Nickel · exportable as JSON · queryable from Nu · verifiable in CI
Reflection — what BECOMES
Ontology = what IS
→ Invariants — structural truth
→ Tensions — living trade-offs
→ State — where we are now
Reflection = what BECOMES
→ Operational modes — sequences with a DAG of dependencies
→ ADRs with typed constraints — living decisions, not prose
→ Structured backlog — tensions → tasks
→ Session history — who did what and when
The ontology captures being. Reflection captures operating on that being.
A mode as an executable specification
# reflection/modes/new_service.ncl
+{
+ id = "new_service",
+ trigger = "When adding a new service boundary",
+ steps = [
+ {
+ id = "draft-adr",
+ actor = "developer",
+ action = "Draft ADR for service boundary decision",
+ },
+ {
+ id = "verify-invariants",
+ actor = "agent",
+ action = "Check no invariant is violated",
+ depends_on = [{ step = "draft-adr" }],
+ },
+ {
+ id = "seal-config",
+ actor = "developer",
+ action = "Apply initial config seal",
+ depends_on = [{ step = "verify-invariants" }],
+ },
+ ],
+}
Not a runbook. A typed acyclic graph. The AI executes it. The system validates it.
AI as an actor, not an oracle
With no formalized ontology
# What the agent receives
+"Help me scale this service"
+
+# What the agent assumes
+- that it can add replicas freely
+- that the current state is the desired one
+- that there are no org constraints
+- that December's decision is irrelevant
+
+# What it generates
+resource "google_compute_instance" {
+ count = 5 # reasonable, right?
+}
With a formalized ontology
# What the agent receives (SessionStart hook)
+INVARIANT: max-replicas-per-zone = 2
+TENSION: scaling vs consistency [unresolved]
+CONSTRAINT (adr-003): no horizontal scaling
+ without explicit capacity review
+STATE: backend-maturity = single-stable
+ → desired: multi-stable
+ → blocker: capacity-review-pending
+
+# What the agent can do
+- Ask whether it is warranted given the blocker
+- Generate the config within the limits
+- Flag that the ADR must be reviewed first
The agent operates on what you already made clear. It stops inventing context because you stopped keeping it implicit.
Who keeps this up to date?
The question that always comes up.
The real problem with the README
✗
Nobody has an incentive to update it — it is not on the critical path
✗
There is no signal for when it is stale
✗
Updating it takes the friction of free-form writing
✗
There is no verification — it can diverge silently
Ontoref’s design
Pre-commit as enforced synchronization
nickel typecheck on every commit — the declarative layer is never left broken
Modes as mandatory procedures
Adding a service runs the mode — the ADR is written as part of the process
Drift detection
sha256(nickel export) — you know when the sealed state differs from the current one
ADRs as constraints, not prose
The constraint is machine-readable — CI can verify it, not just read it
The ontology stays current because it is the path. Not because someone is disciplined.
For the discussion
Thread 1 — Ontology
Isn't a good README enough?
When was the last time yours was up to date?
What sets an ontology apart from a list of decisions?
Structure, queryability, verifiability.
Who maintains this when the project moves fast?
The design makes it mandatory, not optional.
Thread 2 — Infra + AI
Is it different from copying Stack Overflow?
On SO you searched. With the AI, you delegate the search too.
Where is the minimum understanding you need?
Knowing what cannot break. Without that, you have no control.
Do internal platforms solve this, or hide it?
A platform with no ontology just moves the ignorance one level up.
AI can declare your infra.
It cannot understand it for you.
The ontology is the model that forces you to know what is true now. Reflection is the operation over that model. The AI is the actor that operates on what you already made clear.
Typing the invisible. Verifying the obvious. Sealing what matters.
¿Qué estamos resolviendo?
Los problemas
🔴
Epistemic drift El código hace X, el equipo cree que hace Y. Silencioso. Acumulativo.
🔴
Multi-actor collision Humano + agente IA escriben al mismo fichero, sin coordinación.
🟠
Decision amnesia ¿Por qué se tomó esta decisión? ¿Quién la autorizó?
🟠
Config schizophrenia Staging funciona, prod no. ¿Qué campo cambió y cuándo?
🟠
Docs como artefactos muertos Escritas una vez, olvidadas, nunca actualizadas.
🟡
Agent con ceguera Los agentes IA empiezan sin contexto, violan invariantes establecidas.
Ejemplo: desincronización real
# Documentación (2024-01)
+
+
Ontology & Reflection
Typing the invisible. Verifying the obvious. Sealing what matters.
What are we solving?
The problems
🔴
Epistemic drift The code does X, the team believes it does Y. Silent. Cumulative.
🔴
Multi-actor collision Human + AI agent write to the same file, with no coordination.
🟠
Decision amnesia Why was this decision made? Who authorized it?
🟠
Config schizophrenia Staging works, prod doesn't. Which field changed, and when?
🟠
Docs as dead artifacts Written once, forgotten, never updated.
🟡
Agent going in blind AI agents start with no context, violate established invariants.
Example: real desynchronization
# Documentation (2024-01)config.max_retries = 3
-# Código actual (después de cambio sin registrar)
+# Actual code (after an unregistered change)config.max_retries = 7
-# Equipo cree que está usando 3 ✗
-# Sistema usa 7 silenciosamente ✓
-# Nadie sabe cuándo cambió ni por qué
El coste de ignorarlo
Deuda técnica → arreglable
-Deuda epistémica → sistémica
-Deuda de confianza → letal
Técnica
Refactoriza, reescribe, corrige.
1-3 sprints
Epistémica
Acumula silenciosamente. No sabes dónde.
Crece cada semana
Confianza
Se disuelve cuando se descubre el drift.
Imposible reparar rápido
Escenario: 6 meses de ignorar
Mes 1: "Solo refactorizar esto"
-Mes 2: "Documentación está desactualizada"
-Mes 3: "¿Por qué prod falla y staging no?"
-Mes 4: "Nadie sabe quién cambió qué"
-Mes 5: Pánico. Rollback arriesgado.
-Mes 6: Equipo rechaza cambios nuevos.
- "No confiamos sin entender"
Estos problemas no tienen solución técnica. Tienen solución de arquitectura.
Verdad y operación — dos fuerzas que deben coexistir
Yin — la capa formal
Lo que debe ser verdad
Nickel schemas → corrección estructural en tiempo de definición
ADR constraints → "esto nunca puede violarse"
Config seals → estados sellados, verificables con sha256
Ontology invariants → lo que no puede cambiar sin un nuevo ADR
Hashes matemáticos → prueba de qué fue sellado y cuándo
Yang — la capa operacional
Cómo las cosas se mueven y cambian
Nu commands → transformación estructurada de datos
Actors (human/agent/CI) → mismo protocolo, distintas capacidades
Register flow → captura cambios, los enruta al artefacto correcto
Mode definitions → secuencias de operaciones con verificación
Pre-commit hooks → sincronización forzada en el momento del commit
Yang sin Yin = fluido pero caótico. Cualquier cosa puede cambiar. Nada es verificable.
-Yin sin Yang = correcto pero inútil. Schemas perfectos sin operaciones = documentación muerta.
Registros abiertos/cerrados: { _: String } vs { field | String }
nickel export file.ncl → JSON estable pipelines Nu
El sistema de tipos es la documentación.
Por qué no alternativas
YAML → sin tipos, whitespace-sensitive,
- coerciones implícitas
-TOML → sin tipos ≥ primitivos, sin imports
-JSON → sin comentarios, sin imports, sin tipos
-HCL → efectos secundarios, no es config pura
-CUE → similar pero peor historia de imports
-KCL → tipos + validación, pero vendedor
- lenguaje opaco
Por qué aquí específicamente
ADR constraints necesitan typecheck, no validación manual
Perfiles de config deben fallar en definición, no en runtime
nickel export produce JSON estable para consumo Nu
# YAML: silently accepts garbage
+# Team thinks it is using 3 ✗
+# System silently uses 7 ✓
+# Nobody knows when it changed, or why
Month 1: "Just refactor this"
+Month 2: "The docs are out of date"
+Month 3: "Why does prod fail and staging doesn't?"
+Month 4: "Nobody knows who changed what"
+Month 5: Panic. Risky rollback.
+Month 6: Team rejects new changes.
+ "We don't trust what we don't understand"
These problems have no technical solution. They have an architectural one.
Truth and operation — two forces that must coexist
Yin — the formal layer
What must be true
Nickel schemas → structural correctness at definition time
ADR constraints → "this can never be violated"
Config seals → sealed states, verifiable with sha256
Ontology invariants → what cannot change without a new ADR
Mathematical hashes → proof of what was sealed and when
Yang — the operational layer
How things move and change
Nu commands → structured data transformation
Actors (human/agent/CI) → same protocol, different capabilities
Register flow → captures changes, routes them to the right artifact
Mode definitions → sequences of operations with verification
Pre-commit hooks → synchronization enforced at commit time
Yang without Yin = fluid but chaotic. Anything can change. Nothing is verifiable.
+Yin without Yang = correct but useless. Perfect schemas, no operations = dead documentation.
Open/closed records: { _: String } vs { field | String }
nickel export file.ncl → stable JSON for Nu pipelines
The type system is the documentation.
Why not the alternatives
YAML → no types, whitespace-sensitive,
+ implicit coercions
+TOML → no types beyond primitives, no imports
+JSON → no comments, no imports, no types
+HCL → side effects, not pure config
+CUE → similar but worse import story
+KCL → types + validation, but vendor
+ opaque language
Why here specifically
ADR constraints need typecheck, not manual validation
Config profiles must fail at definition, not at runtime
nickel export produces stable JSON for Nu to consume
# YAML: silently accepts garbageactor: developr # typo, accepted# Nickel: rejected at typecheck{ actor | [| 'developer, 'agent, 'ci |] = "developr" }# ^^^^^^^^^
-# error: tag not in enum type
Nushell — datos estructurados, no streams de texto
Shell tradicional: texto opaco
# Bash: parsear texto, error-prone
+# error: tag not in enum type
nickel export adrs/adr-001.ncl | from json | get constraints | where severity == "Hard"
@@ -87,13 +94,13 @@ sort_order: 1
├───┼────────────┼──────────────────────────────┤│ 0 │ adr-001-c1 │ nickel export must succeed… ││ 1 │ adr-001-c2 │ schema is sole source of… │
-╰───┴────────────┴──────────────────────────────╯
Nickel → Nu → Bash — tres capas, tres roles
Nickel exporta JSON tipado
Nunca strings mágicos. Contratos en la definición, no en runtime.
Nu consume estructuras
Tables, records, pipelines. Filter, sort, merge — sin awk ni sed.
Bash orquesta procesos
Locking, signals, exec. Solo lo que bash hace de forma nativa.
# Constraints Hard del sistema completo
+╰───┴────────────┴──────────────────────────────╯
Nickel → Nu → Bash — three layers, three roles
Nickel exports typed JSON
Never magic strings. Contracts at definition, not at runtime.
Nu consumes structures
Tables, records, pipelines. Filter, sort, merge — no awk, no sed.
Bash orchestrates processes
Locking, signals, exec. Only what bash does natively.
# Hard constraints across the whole systemglob "adrs/adr-*.ncl"| each { |f| nickel export $f | complete | get stdout }| each { from json }| where status == "Accepted"| get constraints | flatten
-| where severity == "Hard"
DAGs y FSMs — grafos acíclicos y máquinas de estado
FSM: ciclo de vida de un ADR
┌──────────┐ adr accept ┌──────────┐
+| where severity == "Hard"
Las transiciones inválidas no existen — el tipo las elimina del espacio de posibilidades. Un ADR no puede volver a Proposed. Superseded no puede tener constraints activas.
Invalid transitions do not exist — the type removes them from the space of possibilities. An ADR cannot go back to Proposed. Superseded cannot hold active constraints.
Sin coordinador. Sin TOCTOU. Trazabilidad por actor.
Advisory locks (mkdir)
Serializa escrituras en manifest/changelog/backlog. Stale detection por PID.
Actor-agnostic protocol
El sistema no distingue humano de agente. El protocolo enforcea igual para ambos.
Worktrees aíslan el working-tree (branches diferentes). Locking serializa escrituras sobre el mismo árbol. Son complementarios, no alternativos.
Ontology & Reflection
✓ Typed✓ Verified✓ Sealed✓ Decided
El código y el entendimiento del código deben converger. Los ADRs y la ontología son el contrato entre ambos. La reflection es la operación sobre ese contrato.
Not the config format. The model of what it can contain.
Serde validates shape | Types validate meaning
The compiler validates before the binary exists.
What Rust Gives Us
Answer to Question 1:fail early, fail cheap
// Immutability by default — invariants are invariants
+let config = load_config()?; // cannot change silently
+// Option<T> — no nulls, no assumptions
+let mushrooms: Option<Ingredient> = order.mushrooms;
+match mushrooms {
+ Some(m) => add_to_dish(m),
+ None => notify_kitchen_to_skip(), // explicit. always.
+}
+// Enums as closed domains
+enum CloudProvider { Hetzner, UpCloud, AWS, GCP, Azure, OnPrem }
+enum Port { Valid(u16) } // not any integer — a valid port
Answer to Question 2:explicit contracts
// Traits define what every actor in the chain must fulfill
+#[async_trait]
+pub trait TaskStorage: Send + Sync {
+ async fn create_task(&self, task: WorkflowTask) -> StorageResult<WorkflowTask>;
+ async fn update_task(&self, id: &str, status: TaskStatus) -> StorageResult<()>;
+ // Add a new provider: implement this trait or it doesn't compile
+}
The Compiler as Pre-Validator
Answer to Question 3: guaranteed determinism
// Closed domain — you can't forget a case
+enum RollbackStrategy {
+ ConfigDriven,
+ Conservative, // preserve unless marked deletion
+ Aggressive, // revert all changes
+ Custom { operations: Vec<String> },
+}
+// The compiler enforces exhaustive handling
+match strategy {
+ RollbackStrategy::ConfigDriven => ...,
+ RollbackStrategy::Conservative => ...,
+ RollbackStrategy::Aggressive => ...,
+ RollbackStrategy::Custom { .. } => ...,
+ // miss one → compile error
+}
Thecompilervalidates:
Before building the binary
Not after hours of execution
Not when a function nobody touched in months finally gets called
The compiler is the waiter who validates the order. Before it reaches the kitchen. Before the guest waits. Before any ingredient is missing.
🛡 ●●●●○ 😴 ●●●●○ 🔥 ●●○○○
The Human Impact
When the system is trustworthy:
✓ Sleep comes back
✓ Confidence returns
✓ The team trusts the automation
✓ Stress decreases
✓ You can actually rest
What you can’t measure: fear.
What you can measure: MTTR.
Before: > 30 minutes. Now: < 5 minutes.
🛡 ●●●●● 😴 ●●●●● 🔥 ●○○○○
Continuous CI/CD.
Types. Compiler. Explicit state.
Continuous certainty.
(to keep sleeping well)
🛡 ●●●●● 😴 ●●●●● 🔥 ●○○○○
In Production
This is not theory
🌗
Nickel
YAML rejected. TOML rejected. Reason: no type safety.
YAML wrote what we wanted. It couldn’t say what was possible.
Nickel closes that gap — at config time, not at 3 AM.
# Infrastructure schema
+# — validated at config compile time
+{
+ compute | {
+ region | String,
+ count | Number & (fun n => n > 0),
+ scaling | {
+ min | Number & (fun n => n > 0),
+ max | Number & (fun n => n >= min),
+ # -- compiler verifies this relationship
+ }
+ }
+}
Typed Source of Truth
Result (provisioning ADR-003): zero configuration type errors in production.
Fails 3×: page sent — with full state, checkpoint, and execution history.
You wake up to information. Not to chaos.
🛡 ●●●●● 😴 ●●●●● 🔥 ●○○○○
Without types. Without compiler. Without explicit state.
MTTR > 30 minutes.
────────────────────────
Rust. Types. Explicit state. Automated response.
MTTR < 5 minutes.
(at 3 AM. without you.)
🛡 ●●●●● 😴 ●●●●● 🔥 ●○○○○
Why This Matters
For everyone in this room
For You
If you've been frustrated like me
Rust solves problems you already have.
This is not hype. It is operational relief.
Start here:
Model your infrastructure as types
Let the compiler pre-validate before deployment
If you're earlier in your career
Start with type safety from day one.
Build for reliability, not only speed.
The shortest path:
Types for config.
Traits for providers.
Determinism for operations.
I have perspective from long production experience.
I have seen technologies come and go.
Rust is not hype. Rust is relief with evidence.
It solves real operational problems I had for decades.
More years is not a liability.
It is an advantage.
Why I Needed Rust
🛡 ●●●●●😴 ●●●●●🔥 ●○○○○
Three Closing Lines
I have lived this problem for decades. Rust gave me deterministic systems and better sleep. Start small: model infrastructure as types.
Thank you. Questions?
More info: · jesusperez.pro
· provisioning.systems · vapora.dev · rustelo.dev
+
+
+
+
diff --git a/site/site/content/resources/es/presentaciones/ai-infra.md b/site/site/content/resources/es/presentaciones/ai-infra.md
new file mode 100644
index 0000000..fc6079a
--- /dev/null
+++ b/site/site/content/resources/es/presentaciones/ai-infra.md
@@ -0,0 +1,169 @@
+---
+id: "ai-infra"
+title: "¿La IA gestiona tu infra?"
+slug: "la-ia-gestiona-tu-infra"
+subtitle: ""
+excerpt: ""
+
+author: "Jesús Pérez"
+date: "2026-07-15"
+published: true
+featured: false
+
+category: "presentaciones"
+tags: ["ontoref", "slides"]
+
+# Card + share image. The webp carousel is no longer the CONTENT — the slides carry real text
+# now — but slide 0 still makes the best thumbnail.
+thumbnail: "/images/decks/ai-infra/thumb-es.webp"
+image_url: "/images/decks/ai-infra/thumb-es.webp"
+og_image: "/images/og/decks-ai-infra-thumb-es.png"
+
+sort_order: 1
+---
+
+
+
+
+
+
+
+
+
+
+
+ 1 / 12
+
+
+
+
+
+
+
+
+
La IA gestiona tu infra... ¿Sabes lo que está pasando?
Ontología y Reflection como base de un proyecto que se entiende a sí mismo.
El problema no es la herramienta
Lo que la IA hace bien
✓
Genera YAML correcto sintácticamente
✓
Completa Terraform que nunca rompe el plan
✓
Rellena gaps de configuración con defaults razonables
✓
Traduce intención en forma declarativa
Lo que la IA no puede hacer
✗
Saber por qué ese servicio no puede escalar a N réplicas
✗
Conocer la tensión que existe entre latencia y consistencia en tu sistema
✗
Recordar la decisión que tomaste en diciembre y por qué descartaste la alternativa
✗
Entender qué no puede romperse sin coordinación entre equipos
Declarativo ≠ comprensión. Describes el estado deseado, no el por qué.
Las 2am — cuando el Terraform no habla
Lo que ves cuando falla
Error: Error creating Instance:
+ googleapi: Error 400: Invalid value
+ for field 'resource.machineType'
+
+# El plan pasó. El apply falló.
+# ¿Qué asumió el agente?
+# ¿Qué región eligió? ¿Por qué ese tipo?
+# ¿Hay una restricción de org que no sabía?
# Lo que generó la IA (hace 6 semanas)
+resource "google_compute_instance" "api" {
+ machine_type = "e2-medium" # "razonable"
+ zone = "us-central1-a" # "por defecto"
+}
+
+# Lo que tu política de org requiere
+# → solo europe-west1, solo n2-standard-*
+# → la IA no lo sabía porque tú tampoco lo escribiste
El patrón que se repite
Sin modelo explícito
La IA inventa contexto plausible. Tú asumes que sabe. Falla en prod.
Con Stack Overflow
Copias código sin entender el supuesto. Al menos tú lo buscaste.
Con la IA
El agente genera con confianza. La confianza es contagiosa. El error también.
La diferencia con Stack Overflow: Al menos ahí buscabas activamente. Con la IA, delegas también la búsqueda.
Tu proyecto vive en tu cabeza
Lo que vive solo en tu cabeza
→
Por qué este servicio no puede tener más de 3 réplicas
→
Qué pasó cuando intentamos escalar en enero y por qué fallamos
→
La tensión entre el equipo de plataforma y el de producto sobre quién controla el networking
→
Qué alternativa se rechazó y por qué
→
Qué invariante no puede violarse sin romper el acuerdo con el equipo de seguridad
Lo que vive solo en tu cabeza no se puede validar. No puede consultarlo un agente. No puede consultarlo un compañero nuevo. No puedes consultarlo tú mismo en 6 meses.
La trampa del README
# Mi Proyecto
+
+Este servicio hace X. Está desplegado en GCP.
+Usa Terraform. Tiene 3 entornos: dev, staging, prod.
+
+## Arquitectura
+Ver diagrama (desactualizado desde marzo).
+
+## Decisiones
+- Elegimos PostgreSQL porque MySQL no nos gustaba.
+- Usamos gRPC internamente.
✗
No dice qué no puede cambiar
✗
No captura las alternativas rechazadas ni el por qué
✗
No es consultable ni verificable — es prosa
✗
No refleja el estado actual — refleja el estado de cuando se escribió
La tesis
La ontología no es para la IA.
Es para ti.
Formalizar invariantes, tensiones y estado actual te fuerza a saber qué es verdad ahora mismo.
La IA se beneficia como efecto secundario. Opera sobre lo que tú ya clarificaste.
El valor real: el proceso de escribir la ontología es donde te aclaras tú, no la IA.
Ontología ≠ lista de decisiones
Una lista de decisiones
- Elegimos Kubernetes
+- Usamos Helm para despliegues
+- PostgreSQL como base de datos primaria
+- gRPC entre servicios internos
+- OAuth2 para autenticación externa
Captura el qué. No captura el por qué, las alternativas rechazadas, ni las consecuencias.
Una ontología
INVARIANTES
Lo que no puede cambiar sin decisión explícita y coordinación
TENSIONES ACTIVAS
Trade-offs que aún no se han resuelto — viven en el sistema ahora mismo
ESTADO ACTUAL → DESEADO
Dimensiones de madurez. Dónde estás, dónde quieres estar, qué te bloquea
GATES ACTIVAS
Condiciones que deben cumplirse antes de cruzar una frontera arquitectural
Es un grafo consultable. No prosa. La IA puede leerlo. Tu CI puede verificarlo. Tú puedes razonarlo.
Nickel tipado · exportable como JSON · consultable desde Nu · verificable en CI
Reflection — lo que se CONVIERTE
Ontología = lo que ES
→ Invariantes — verdad estructural
→ Tensiones — trade-offs vivos
→ Estado — dónde estamos ahora
Reflection = lo que DEVIENE
→ Modos operacionales — secuencias con DAG de dependencias
→ ADRs con constraints tipadas — decisiones vivas, no prosa
→ Backlog estructurado — tensiones → tareas
→ Historial de sesiones — quién hizo qué y cuándo
La ontología captura el ser. La reflection captura el operar sobre ese ser.
Un modo como especificación ejecutable
# reflection/modes/new_service.ncl
+{
+ id = "new_service",
+ trigger = "When adding a new service boundary",
+ steps = [
+ {
+ id = "draft-adr",
+ actor = "developer",
+ action = "Draft ADR for service boundary decision",
+ },
+ {
+ id = "verify-invariants",
+ actor = "agent",
+ action = "Check no invariant is violated",
+ depends_on = [{ step = "draft-adr" }],
+ },
+ {
+ id = "seal-config",
+ actor = "developer",
+ action = "Apply initial config seal",
+ depends_on = [{ step = "verify-invariants" }],
+ },
+ ],
+}
No es un runbook. Es un grafo acíclico tipado. La IA lo ejecuta. El sistema lo valida.
La IA como actor, no como oráculo
Sin ontología formalizada
# Lo que el agente recibe
+"Ayúdame a escalar este servicio"
+
+# Lo que el agente asume
+- que puede añadir réplicas libremente
+- que el estado actual es el deseado
+- que no hay restricciones de org
+- que la decisión de diciembre es irrelevante
+
+# Lo que genera
+resource "google_compute_instance" {
+ count = 5 # razonable, ¿no?
+}
Con ontología formalizada
# Lo que el agente recibe (SessionStart hook)
+INVARIANT: max-replicas-per-zone = 2
+TENSION: scaling vs consistency [unresolved]
+CONSTRAINT (adr-003): no horizontal scaling
+ without explicit capacity review
+STATE: backend-maturity = single-stable
+ → desired: multi-stable
+ → blocker: capacity-review-pending
+
+# Lo que el agente puede hacer
+- Preguntar si procede dado el bloqueador
+- Generar la config dentro de los límites
+- Indicar que el ADR debe revisarse antes
El agente opera sobre lo que tú ya clarificaste. Deja de inventarse contexto porque tú dejaste de tenerlo implícito.
¿Quién mantiene esto actualizado?
La pregunta que siempre sale.
El problema real con el README
✗
Nadie tiene incentivo para actualizarlo — no está en el path crítico
✗
No hay señal de cuando está desactualizado
✗
Actualizar requiere fricción de escritura libre
✗
No hay verificación — puede divergir silenciosamente
El diseño de ontoref
Pre-commit como sincronización forzada
nickel typecheck en cada commit — la capa declarativa nunca queda rota
Modos como procedimientos obligatorios
Añadir un servicio ejecuta el modo — el ADR se escribe como parte del proceso
Drift detection
sha256(nickel export) — sabes cuándo el estado sellado difiere del actual
ADRs como constraints, no prosa
El constraint es machine-readable — el CI puede verificarlo, no solo leerlo
La ontología se mantiene porque es el path. No porque alguien sea disciplinado.
Para el debate
Propuesta 1 — Ontología
¿No es suficiente con un buen README?
¿Cuándo fue la última vez que el tuyo estaba al día?
¿Qué diferencia una ontología de una lista de decisiones?
Estructura, consultabilidad, verificabilidad.
¿Quién mantiene esto cuando el proyecto cambia rápido?
El diseño lo hace obligatorio, no opcional.
Propuesta 2 — Infra + IA
¿Es diferente a copiar Stack Overflow?
En SO buscabas. Con la IA, delegas también la búsqueda.
¿Dónde está el mínimo de comprensión necesario?
Saber qué no puede romperse. Sin eso, no tienes control.
¿Las plataformas internas resuelven esto o lo esconden?
Una plataforma sin ontología solo mueve la ignorancia un nivel arriba.
La IA puede declarar tu infra.
No puede entenderla por ti.
La ontología es el modelo que te fuerza a saber qué es verdad ahora. La reflection es la operación sobre ese modelo. La IA es el actor que opera sobre lo que ya clarificaste.
+ aria-label="Presentación de 16 diapositivas. Con el foco puesto, las flechas o la barra espaciadora navegan.">
@@ -42,12 +42,19 @@ sort_order: 1
+
-
Ontology & Reflection
Typing the invisible. Verifying the obvious. Sealing what matters.
¿Qué estamos resolviendo?
Los problemas
🔴
Epistemic drift El código hace X, el equipo cree que hace Y. Silencioso. Acumulativo.
🔴
Multi-actor collision Humano + agente IA escriben al mismo fichero, sin coordinación.
🟠
Decision amnesia ¿Por qué se tomó esta decisión? ¿Quién la autorizó?
🟠
Config schizophrenia Staging funciona, prod no. ¿Qué campo cambió y cuándo?
🟠
Docs como artefactos muertos Escritas una vez, olvidadas, nunca actualizadas.
🟡
Agent con ceguera Los agentes IA empiezan sin contexto, violan invariantes establecidas.
Ejemplo: desincronización real
# Documentación (2024-01)
+
+
Ontology & Reflection
Typing the invisible. Verifying the obvious. Sealing what matters.
¿Qué estamos resolviendo?
Los problemas
🔴
Epistemic drift El código hace X, el equipo cree que hace Y. Silencioso. Acumulativo.
🔴
Multi-actor collision Humano + agente IA escriben al mismo fichero, sin coordinación.
🟠
Decision amnesia ¿Por qué se tomó esta decisión? ¿Quién la autorizó?
🟠
Config schizophrenia Staging funciona, prod no. ¿Qué campo cambió y cuándo?
🟠
Docs como artefactos muertos Escritas una vez, olvidadas, nunca actualizadas.
🟡
Agent con ceguera Los agentes IA empiezan sin contexto, violan invariantes establecidas.
Ejemplo: desincronización real
# Documentación (2024-01)config.max_retries = 3# Código actual (después de cambio sin registrar)
@@ -55,7 +62,7 @@ sort_order: 1
# Equipo cree que está usando 3 ✗# Sistema usa 7 silenciosamente ✓
-# Nadie sabe cuándo cambió ni por qué
El coste de ignorarlo
Deuda técnica → arreglable
+# Nadie sabe cuándo cambió ni por qué
El coste de ignorarlo
Deuda técnica → arreglableDeuda epistémica → sistémicaDeuda de confianza → letal
Técnica
Refactoriza, reescribe, corrige.
1-3 sprints
Epistémica
Acumula silenciosamente. No sabes dónde.
Crece cada semana
Confianza
Se disuelve cuando se descubre el drift.
Imposible reparar rápido
Escenario: 6 meses de ignorar
Mes 1: "Solo refactorizar esto"Mes 2: "Documentación está desactualizada"
@@ -63,8 +70,8 @@ sort_order: 1
Mes 4: "Nadie sabe quién cambió qué"Mes 5: Pánico. Rollback arriesgado.Mes 6: Equipo rechaza cambios nuevos.
- "No confiamos sin entender"
Estos problemas no tienen solución técnica. Tienen solución de arquitectura.
Verdad y operación — dos fuerzas que deben coexistir
Yin — la capa formal
Lo que debe ser verdad
Nickel schemas → corrección estructural en tiempo de definición
ADR constraints → "esto nunca puede violarse"
Config seals → estados sellados, verificables con sha256
Ontology invariants → lo que no puede cambiar sin un nuevo ADR
Hashes matemáticos → prueba de qué fue sellado y cuándo
Yang — la capa operacional
Cómo las cosas se mueven y cambian
Nu commands → transformación estructurada de datos
Actors (human/agent/CI) → mismo protocolo, distintas capacidades
Register flow → captura cambios, los enruta al artefacto correcto
Mode definitions → secuencias de operaciones con verificación
Pre-commit hooks → sincronización forzada en el momento del commit
Yang sin Yin = fluido pero caótico. Cualquier cosa puede cambiar. Nada es verificable.
-Yin sin Yang = correcto pero inútil. Schemas perfectos sin operaciones = documentación muerta.
Registros abiertos/cerrados: { _: String } vs { field | String }
nickel export file.ncl → JSON estable pipelines Nu
El sistema de tipos es la documentación.
Por qué no alternativas
YAML → sin tipos, whitespace-sensitive,
+ "No confiamos sin entender"
Estos problemas no tienen solución técnica. Tienen solución de arquitectura.
Verdad y operación — dos fuerzas que deben coexistir
Yin — la capa formal
Lo que debe ser verdad
Nickel schemas → corrección estructural en tiempo de definición
ADR constraints → "esto nunca puede violarse"
Config seals → estados sellados, verificables con sha256
Ontology invariants → lo que no puede cambiar sin un nuevo ADR
Hashes matemáticos → prueba de qué fue sellado y cuándo
Yang — la capa operacional
Cómo las cosas se mueven y cambian
Nu commands → transformación estructurada de datos
Actors (human/agent/CI) → mismo protocolo, distintas capacidades
Register flow → captura cambios, los enruta al artefacto correcto
Mode definitions → secuencias de operaciones con verificación
Pre-commit hooks → sincronización forzada en el momento del commit
Yang sin Yin = fluido pero caótico. Cualquier cosa puede cambiar. Nada es verificable.
+Yin sin Yang = correcto pero inútil. Schemas perfectos sin operaciones = documentación muerta.
Registros abiertos/cerrados: { _: String } vs { field | String }
nickel export file.ncl → JSON estable pipelines Nu
El sistema de tipos es la documentación.
Por qué no alternativas
YAML → sin tipos, whitespace-sensitive, coerciones implícitasTOML → sin tipos ≥ primitivos, sin importsJSON → sin comentarios, sin imports, sin tipos
@@ -76,7 +83,7 @@ sort_order: 1
# Nickel: rejected at typecheck{ actor | [| 'developer, 'agent, 'ci |] = "developr" }# ^^^^^^^^^
-# error: tag not in enum type
Nushell — datos estructurados, no streams de texto
Shell tradicional: texto opaco
# Bash: parsear texto, error-prone
+# error: tag not in enum type
Nushell — datos estructurados, no streams de texto
nickel export adrs/adr-001.ncl | from json
@@ -93,7 +100,7 @@ sort_order: 1
| each { from json }| where status == "Accepted"| get constraints | flatten
-| where severity == "Hard"
DAGs y FSMs — grafos acíclicos y máquinas de estado
FSM: ciclo de vida de un ADR
┌──────────┐ adr accept ┌──────────┐
+| where severity == "Hard"
DAGs y FSMs — grafos acíclicos y máquinas de estado
FSM: ciclo de vida de un ADR
┌──────────┐ adr accept ┌──────────┐ │ Proposed │ ───────────▶ │ Accepted │ └──────────┘ └──────────┘ │ new ADR
@@ -113,7 +120,7 @@ sort_order: 1
nickel export .ontology/core.ncl| from json | get nodos| where invariante == true
-| select id descripcion
La Ontología Operacional — el grafo operacional
core.ncl — lo que no puede cambiar
# .ontology/core.ncl
+| select id descripcion
La Ontología Operacional — el grafo operacional
core.ncl — lo que no puede cambiar
# .ontology/core.ncl{ nodos = [ {
@@ -131,7 +138,7 @@ sort_order: 1
| from json | get membranas| where activa == true| select id permeabilidad protege
stratum config verify development → compara hash actual con hash sellado
ADRs vivos
— de documento muerto a constraint machine
Estructura Nickel de un ADR
# adrs/adr-001-nickel-as-canonical.ncllet s = import "adrs/schema.ncl" in{ id = "adr-001",
@@ -199,7 +206,7 @@ sort_order: 1
| where status == "Accepted"| get constraints | flatten| where severity == "Hard"
-| select id claim
El conjunto activo de constraints es el contrato en vigor — no la prosa del ADR. La prosa explica el porqué. Los constraints enforcan el qué.
Implementación — las partes y cómo encajan
Stack de archivos operativos
stratum.sh ← entry point, locking, env
+| select id claim
El conjunto activo de constraints es el contrato en vigor — no la prosa del ADR. La prosa explica el porqué. Los constraints enforcan el qué.
Sin coordinador. Sin TOCTOU. Trazabilidad por actor.
Advisory locks (mkdir)
Serializa escrituras en manifest/changelog/backlog. Stale detection por PID.
Actor-agnostic protocol
El sistema no distingue humano de agente. El protocolo enforcea igual para ambos.
Worktrees aíslan el working-tree (branches diferentes). Locking serializa escrituras sobre el mismo árbol. Son complementarios, no alternativos.
Ontology & Reflection
✓ Typed✓ Verified✓ Sealed✓ Decided
El código y el entendimiento del código deben converger. Los ADRs y la ontología son el contrato entre ambos. La reflection es la operación sobre ese contrato.
Sin coordinador. Sin TOCTOU. Trazabilidad por actor.
Advisory locks (mkdir)
Serializa escrituras en manifest/changelog/backlog. Stale detection por PID.
Actor-agnostic protocol
El sistema no distingue humano de agente. El protocolo enforcea igual para ambos.
Worktrees aíslan el working-tree (branches diferentes). Locking serializa escrituras sobre el mismo árbol. Son complementarios, no alternativos.
Ontology & Reflection
✓ Typed✓ Verified✓ Sealed✓ Decided
El código y el entendimiento del código deben converger. Los ADRs y la ontología son el contrato entre ambos. La reflection es la operación sobre ese contrato.
Gracias. ¿Preguntas?
jesusperez.pro · ontoref.dev
-
+
diff --git a/site/site/content/resources/es/presentaciones/rustikon.md b/site/site/content/resources/es/presentaciones/rustikon.md
new file mode 100644
index 0000000..c7ac139
--- /dev/null
+++ b/site/site/content/resources/es/presentaciones/rustikon.md
@@ -0,0 +1,162 @@
+---
+id: "rustikon"
+title: "Por qué necesité Rust"
+slug: "por-que-necesite-rust"
+subtitle: ""
+excerpt: ""
+
+author: "Jesús Pérez"
+date: "2026-07-15"
+published: true
+featured: false
+
+category: "presentaciones"
+tags: ["ontoref", "slides"]
+
+# Card + share image. The webp carousel is no longer the CONTENT — the slides carry real text
+# now — but slide 0 still makes the best thumbnail.
+thumbnail: "/images/decks/rustikon/thumb-es.webp"
+image_url: "/images/decks/rustikon/thumb-es.webp"
+og_image: "/images/og/decks-rustikon-thumb-es.png"
+
+sort_order: 1
+---
+
+
+
+
+
+
+
+
+
+
+
+ 1 / 35
+
+
+
+
+
+
+
+
+
Por qué necesité Rust
Por fin, automatización de infraestructura con la que puedo dormir
🛡 ●●●○○ 😴 ●●●○○ 🔥 ●○○○○
💻
1
Años. Un problema.
1988 → hoy
Época
Herramienta
Lección
Años 90
Perl
El poder sin seguridad es un desastre
Años 2000
Python
El pragmatismo sin garantías es frágil
Años 2010
Bash · Chef · Ansible · Terraform
Más herramientas no resuelven problemas de paradigma
Años 2020
Go · ???
Cada vez creí que tenía la respuesta. Cada vez la realidad me demostró lo contrario.
La evolución
Cómo hemos llegado hasta aquí
Etapa 1 — Local (finales de los 80 / principios de los 90)
Terminales tontos. Una sola máquina. Un solo estado.
Desarrollo local, ciclos de despliegue largos, poca urgencia
Un solo estado — fácil de observar, fácil de controlar
IaC: scripts procedimentales, lógica escondida dentro de la aplicación
La era Perl: podíamos hacer cualquier cosa.
También podíamos romper cualquier cosa.
Metaprogramación bella y aterradora.
Sin red de seguridad.
Fallos silenciosos a las 3 de la mañana.
Lección: el poder sin seguridad es un desastre.
🛡 ●●●●○ 😴 ●●●●○ 🔥 ●○○○○
Etapa 2 — Redes / Internet
Los sistemas se alejan. Más gente. Más coordinación.
Acceso remoto, equipos distribuidos, la seguridad pasa a ser relevante
El coste de la caída sube — los procesos se vuelven críticos
Armonizar: instalación de paquetes, configuración y actualizaciones en varias máquinas en paralelo
IaC: automatización reproducible, primeros intentos declarativos
La era Python: desarrollo rápido, gran comunidad.
Pero nada te impedía equivocarte.
Las anotaciones de tipos llegaron tarde — y opcionales.
Errores en tiempo de ejecución >> errores en tiempo de compilación.
Lección: el pragmatismo sin garantías es frágil.
Más piezas. Más gente. La cosa se pone interesante.
🛡 ●●●○○ 😴 ●●●○○ 🔥 ●●○○○
Etapa 3 — Contenedores / Nube / CI-CD
Todo. En todas partes. Al mismo tiempo.
Monolito → distribuido, 24×7×365, alta disponibilidad
No el formato de configuración. El modelo de lo que puede contener.
Serde valida la forma | Los tipos validan el significado
El compilador valida antes de que el binario exista.
Lo que Rust nos da
Respuesta a la pregunta 1:fallar pronto, fallar barato
// Immutability by default — invariants are invariants
+let config = load_config()?; // cannot change silently
+// Option<T> — no nulls, no assumptions
+let mushrooms: Option<Ingredient> = order.mushrooms;
+match mushrooms {
+ Some(m) => add_to_dish(m),
+ None => notify_kitchen_to_skip(), // explicit. always.
+}
+// Enums as closed domains
+enum CloudProvider { Hetzner, UpCloud, AWS, GCP, Azure, OnPrem }
+enum Port { Valid(u16) } // not any integer — a valid port
Respuesta a la pregunta 2:contratos explícitos
// Traits define what every actor in the chain must fulfill
+#[async_trait]
+pub trait TaskStorage: Send + Sync {
+ async fn create_task(&self, task: WorkflowTask) -> StorageResult<WorkflowTask>;
+ async fn update_task(&self, id: &str, status: TaskStatus) -> StorageResult<()>;
+ // Add a new provider: implement this trait or it doesn't compile
+}
El compilador como prevalidador
Respuesta a la pregunta 3: determinismo garantizado
// Closed domain — you can't forget a case
+enum RollbackStrategy {
+ ConfigDriven,
+ Conservative, // preserve unless marked deletion
+ Aggressive, // revert all changes
+ Custom { operations: Vec<String> },
+}
+// The compiler enforces exhaustive handling
+match strategy {
+ RollbackStrategy::ConfigDriven => ...,
+ RollbackStrategy::Conservative => ...,
+ RollbackStrategy::Aggressive => ...,
+ RollbackStrategy::Custom { .. } => ...,
+ // miss one → compile error
+}
Elcompiladorvalida:
Antes de construir el binario
No después de horas de ejecución
No cuando por fin se llama a una función que nadie tocaba desde hace meses
Comportamiento predecible: memoria, recursos, flujos de trabajo
El compilador es el camarero que valida el pedido. Antes de que llegue a la cocina. Antes de que el cliente espere. Antes de que falte ningún ingrediente.
🛡 ●●●●○ 😴 ●●●●○ 🔥 ●●○○○
El impacto humano
Cuando el sistema es de fiar:
✓ Vuelve el sueño
✓ Vuelve la confianza
✓ El equipo confía en la automatización
✓ Baja el estrés
✓ Puedes descansar de verdad
Lo que no se puede medir: el miedo.
Lo que sí se puede medir: el MTTR.
Antes: > 30 minutos. Ahora: < 5 minutos.
🛡 ●●●●● 😴 ●●●●● 🔥 ●○○○○
CI/CD continuo.
Tipos. Compilador. Estado explícito.
Certeza continua.
(para seguir durmiendo bien)
🛡 ●●●●● 😴 ●●●●● 🔥 ●○○○○
En producción
Esto no es teoría
🌗
Nickel
YAML descartado. TOML descartado. Motivo: sin seguridad de tipos.
YAML escribía lo que queríamos. No sabía decir qué era posible.
Nickel cierra esa brecha — en tiempo de configuración, no a las 3 de la mañana.
# Infrastructure schema
+# — validated at config compile time
+{
+ compute | {
+ region | String,
+ count | Number & (fun n => n > 0),
+ scaling | {
+ min | Number & (fun n => n > 0),
+ max | Number & (fun n => n >= min),
+ # -- compiler verifies this relationship
+ }
+ }
+}
Fuente de verdad tipada
Resultado (ADR-003 de provisioning): cero errores de tipo de configuración en producción.
Cada dependencia es un `DependencyType`. El compilador atrapa: instalar Cilium sin Kubernetes. No el ingeniero de guardia a las 2 de la mañana.
«En mi máquina funciona» aquí se paga.
Esta es la infraestructura de mayor riesgo de toda la charla.
Validadores de blockchain
Los validadores exigen una disponibilidad brutal. Un validador que falla pierde fondos — y no es el dinero de tu infraestructura. Es el de tu cliente.
Criptografía poscuántica: híbrido CRYSTALS-Kyber + Falcon + AES-256-GCM. Claves de validador protegidas frente a ordenadores cuánticos.
SLOs con presupuestos de error reales: 99.99% = 52.6 min de caída al año. Prometheus bloquea los despliegues cuando la tasa de consumo excede el presupuesto.
Configuración determinista: los parámetros del validador son tipos. Un bond_amount que no sea un u128 válido no compila.
Recuperación ante desastres
El rollback como tipo, no como procedimiento
Las 3 de la mañana. Algo se ha roto. Necesitas hacer un rollback. Sin tipos: improvisas. Con tipos: eliges una estrategia — o no compila.
// Checkpoint = complete system snapshot
+pub struct Checkpoint {
+ pub workflow_state: Option<WorkflowExecutionState>,
+ pub resources: Vec<ResourceSnapshot>,
+ pub provider_states: HashMap<String, ProviderState>,
+}
+// Rollback strategy = typed choice, not a runbook
+enum RollbackStrategy {
+ ConfigDriven,
+ Conservative, // preserve unless marked for deletion
+ Aggressive, // revert all changes
+ Custom { operations: Vec<String> },
+}
+// You cannot do rollback without choosing a strategy.
+// The compiler doesn't let you ignore the case.
Copia de seguridad multi-backend: restic, borg, tar, rsync — todos como variantes de un enum.
La copia de seguridad de producción y la restauración de recuperación usan el mismo tipo, el mismo esquema.
El runbook existe.
Nadie lo lee con claridad a las 3 de la mañana y bajo presión.
El tipo fuerza la decisión antes de la crisis.
El estado es el mismo en producción y en recuperación. Siempre.
Autorreparación
Cuando algo se rompe a las 3 de la mañana — responde el sistema, no tú.
enum RemediationAction {
+ ScaleService { service: String, replicas: u32 },
+ FailoverService { service: String, region: Region },
+ RestartService { service: String },
+ ClearCache { service: String, scope: CacheScope },
+}
+// Typed playbooks. Not shell scripts. Not hope.
+// Fails 3 times → escalates to human.
+// Never loops indefinitely.
— Remediación tipada
Lo que pasa a las 3 de la mañana:
Salta la alerta → RemediationEngine casa la condición → ejecuta RestartService
Funciona: silencio. Nadie se despierta.
Falla 3×: se envía el aviso — con el estado completo, el checkpoint y el historial de ejecución.
Te despiertas con información. No con caos.
🛡 ●●●●● 😴 ●●●●● 🔥 ●○○○○
Sin tipos. Sin compilador. Sin estado explícito.
MTTR > 30 minutos.
────────────────────────
Rust. Tipos. Estado explícito. Respuesta automatizada.
MTTR < 5 minutos.
(a las 3 de la mañana. sin ti.)
🛡 ●●●●● 😴 ●●●●● 🔥 ●○○○○
Por qué esto importa
Para todos los que estáis en esta sala
Para ti
Si te has sentido tan frustrado como yo
Rust resuelve problemas que ya tienes.
Esto no es hype. Es alivio operativo.
Empieza por aquí:
Modela tu infraestructura como tipos
Deja que el compilador prevalide antes del despliegue
Si estás más al principio de tu carrera
Empieza con seguridad de tipos desde el primer día.
Construye buscando fiabilidad, no solo velocidad.
El camino más corto:
Tipos para la configuración.
Traits para los proveedores.
Determinismo para las operaciones.
Tengo la perspectiva de una larga experiencia en producción.
He visto tecnologías ir y venir.
Rust no es hype. Rust es alivio con evidencia.
Resuelve problemas operativos reales que arrastré durante décadas.
Más años no son un lastre.
Son una ventaja.
Por qué necesité Rust
🛡 ●●●●●😴 ●●●●●🔥 ●○○○○
Tres frases de cierre
He vivido este problema durante décadas. Rust me dio sistemas deterministas y mejor sueño. Empieza poco a poco: modela la infraestructura como tipos.
Gracias. ¿Preguntas?
Más información: · jesusperez.pro
· provisioning.systems · vapora.dev · rustelo.dev
+
+
+
+
diff --git a/site/site/i18n/locales/en/auth.ftl b/site/site/i18n/locales/en/auth.ftl
index dc283ef..ad02b7e 100644
--- a/site/site/i18n/locales/en/auth.ftl
+++ b/site/site/i18n/locales/en/auth.ftl
@@ -123,4 +123,8 @@ auth-email-otp-subject = Your verification code
auth-email-otp-title = Your verification code
auth-email-otp-subtitle = Use this code to sign in:
auth-email-otp-expire-msg = This code expires in %minutes% minutes.
-auth-email-otp-ignore-msg = If you didn't request this, you can safely ignore this email.
\ No newline at end of file
+auth-email-otp-ignore-msg = If you didn't request this, you can safely ignore this email.
+# SEO for the /login route (LoginPage → login). Lives here because every login
+# string does; Fluent merges the locale's files into one bundle.
+login-page-title = Sign In
+login-page-description = Sign in to your account.
diff --git a/site/site/i18n/locales/en/common.ftl b/site/site/i18n/locales/en/common.ftl
index 71653a9..3e7e481 100644
--- a/site/site/i18n/locales/en/common.ftl
+++ b/site/site/i18n/locales/en/common.ftl
@@ -22,3 +22,9 @@ common-spanish = Spanish
# Image viewer
common-expand-image = Expand
common-close = Close
+
+# Footer. The column holds the two legal pages and the note on language; the latter obliges
+# nobody — it is a style contract — so the column cannot be called "Legal" without misdescribing
+# what is in it.
+footer-legal-title = Terms & style
+footer-social-title = Connect
diff --git a/site/site/i18n/locales/en/pages/about-us.ftl b/site/site/i18n/locales/en/pages/about-us.ftl
index 71894fd..6643fdd 100644
--- a/site/site/i18n/locales/en/pages/about-us.ftl
+++ b/site/site/i18n/locales/en/pages/about-us.ftl
@@ -6,4 +6,25 @@ nav-about-us = About Us
# Page Metadata
about-us-page-title = About Us
about-us-page-subtitle = The people and the practice behind Ontoref.
-about-us-page-description = Ontoref is designed and maintained by Jesús Pérez, a Rust developer and provisioning-systems architect with over three decades in software. It grows from hands-on work with self-hosted, open-source infrastructure and from a conviction that systems should carry their own reasoning: an explicit ontology, recorded decisions, and disciplined reflection. We build small, sovereign tools that organizations can truly own and control, and we share the protocol and its practice openly with a growing community of collaborators.
+about-us-page-description = Ontoref is designed and maintained by Jesús Pérez, a Rust developer and provisioning-systems architect with over three decades in software. It did not start on a blank page: it comes from years of hands-on work with self-hosted, open-source infrastructure, and from a conviction that fits in one sentence — a system must carry its own reasoning.
+
+# Who
+about-us-h-quien = Who is behind it
+about-us-quien-1 = One person, and the open work of a growing community. Authorship matters here for a concrete reason: every practice the protocol imposes exists because its absence once cost something. Ontoref is distilled from real systems that drifted, not designed on paper.
+about-us-quien-2 = The craft is the ordinary one — Rust for what executes, Nickel for what is declared, Nushell for what orchestrates — with the discipline of someone who has had to keep in production what he wrote ten years ago.
+
+# Why
+about-us-h-porque = Why ontoref exists
+about-us-porque-1 = Because a project's knowledge lives where nobody can query it: in the head of whoever built it, in a chat thread, in a README that already lies. When that person leaves — or when an AI agent writes half the code — nothing is left to answer the question that matters: why is this the way it is, and what breaks if I change it?
+about-us-porque-2 = Ontoref's answer is to declare the reasoning: axioms, tensions, practices, state and gates as typed NCL — queryable and verifiable. A protocol, never a runtime dependency. What it actually does is laid out in About ontoref.
+
+# How
+about-us-h-como = How we work
+about-us-como-1 = By an uncomfortable rule: a check nobody has seen refuse is not a check. Before trusting a gate you must falsify it — break, on purpose, the thing it should catch, and confirm that it names it. If you have only ever seen it pass, all you know is that it can say yes.
+about-us-como-2 = And by a second one: failures get published. When something drifts we open a case file — the failure, its root cause, and what stayed in the repository so it cannot happen again. They are public, named and dated, in Case Files. Architecture decisions, with their live constraints, in ADR.
+about-us-como-3 = This is not transparency as a gesture. A system that records its own drifts is a system that someone who was not there can audit — which is, precisely, the problem ontoref sets out to solve.
+
+# Open
+about-us-h-abierto = Open and sovereign
+about-us-abierto-1 = Small tools an organization can genuinely own and control: no SaaS in the middle, no hostages, protocol and practice shared in the open. You enter with a single NCL file and climb tiers only when it hurts.
+about-us-abierto-2 = If any of this resonates — or if you think it is wrong and want to say so — get in touch.
diff --git a/site/site/i18n/locales/en/pages/conceptos.ftl b/site/site/i18n/locales/en/pages/conceptos.ftl
new file mode 100644
index 0000000..df398ef
--- /dev/null
+++ b/site/site/i18n/locales/en/pages/conceptos.ftl
@@ -0,0 +1,10 @@
+# GENERATED from .ontoref/ontology/glossary.ncl by gen-conceptos.nu — do not edit by hand.
+# One source: the same glossary `ontoref describe term` answers from.
+conceptos-page-title = Key concepts — ontoref
+conceptos-page-subtitle = The words this project uses, and what they mean
+conceptos-page-description = The ontoref vocabulary: each concept defined once, with its category, where it comes from, and what it relates to.
+conceptos-page-keywords = glossary, concepts, ontology, reflection, ADR, ondaod, spiral, synthesis
+conceptos-intro = This glossary is not written here. It is projected from .ontoref/ontology/glossary.ncl — the same file «ontoref describe term» answers from in the terminal. Change a definition once, and it changes in both.
+conceptos-more = Learn more →
+conceptos-count = 20
+conceptos-html =
DAG-Formalized Knowledge
Conceptcomes from Axiom · dag-formalizedProject axiom: all project knowledge — concepts, tensions, decisions, state — is formalized as directed acyclic graphs. Enables transversal queries, impact analysis and ecosystem-level visibility. The 'dao-formalized' spelling that occasionally appears in conversation is folklore for the same axiom.related: on+re
Domain (repo_kind CLI extension)
Conceptcomes from ADR · adr-064A repo_kind-activated CLI extension under code/domains/{"{"}id{"}"}/: a project's repo_kind turns on its domain, giving project-type-aware commands (e.g. DD7pasos→knowledge-works, DevWorkspace→provisioning). ALL code/domains/* are domains. `schema_cmd` names WHERE a domain's schema lives (in ontoref vs the implementing project) — it is a schema-location field, NOT federation.related: Door (marketing funnel entry), Projection (constellation member)Learn more →
Door (marketing funnel entry)
Conceptcomes from ADR · adr-064One of the outward funnel entries projected from spine.ncl (ADR-057/064): developer / infrastructure / authoring / personal. A door is an AUDIENCE-facing routing hook that carries a content `tag` (e.g. developer, knowledge-works) and routes to real content, never argues the core. ADR-064 fixes FOUR doors — an axis distinct from the FIVE domains and the ONE convergence membrane.related: Domain (repo_kind CLI extension), Projection (positioning reveal)Learn more →
Encargo (work commission)DRAFT
PracticeUmbrella for the governance unit that constrains an agent by checking the deliverable against explicit terms instead of trusting the operator. An Encargo = one SOW (the terms) + its Work Orders (the executions). Two atomic rules make it a habit: (1) no scope + contract, no start; (2) no witness, no done. Each element kills a specific failure: minimal scope kills drift, falsifiable contract kills unverified prose, witness kills "trust my word", external ownership kills the fox-built-the-henhouse, contained verdict kills the propagation of broken code.related: Statement of Work (SOW), Work Order (WO), Verified witness, Gate
Gate
Artifactcomes from Schema · ontology/schemas/gate.nclTyped prerequisites and policies controlling FSM state transitions in a project. Lives at `.ontology/gate.ncl`. Each dimension declares the conditions a transition must satisfy (catalysts present, blockers cleared); the reflection layer evaluates the gate before allowing a state change.related: on+re
Glossary Extension Pattern
Practicecomes from Axiom · no-enforcementThree-level inheritance for vocabulary: a protocol seed at reflection/defaults/glossary.ncl shipped with ontoref; project terms appended in .ontology/glossary.ncl::project_terms via d.seed_terms @ project_terms; optional domain splits in .ontology/glossary/.ncl when a project grows past ~30 terms. No merge, no copy of the seed into projects — inheritance through import. Local edits to the protocol seed are forbidden; redefining a protocol id locally is caught by the drift hook. Link local terms to protocol ones via related_terms to weave the lexicon across levels.related: on+re, Ondaod, PAP, DAG-Formalized Knowledge
Ondaod
Disciplinecomes from Tension · ontology-vs-reflectionOntoref Dao Discipline. Before architectural analysis or ADR drafting, read the named tensions in core.ncl, identify which the question engages, and describe the synthesis state and direction of motion — do not collapse the Spiral by picking one pole. Two-layer canonical content via the installed CLI: `ontoref qa show ontoref-dao-discipline --format json` for the protocol baseline, and `ontoref qa show -dao-discipline --format json` for project-specific extensions.related: Spiral, Synthesis, Yin/Yang Collapse, adr?
PAP
Conceptcomes from Axiom · self-describingProject's Architecture Principles. The active set of invariants, patterns and rules that define how a specific project is built — drawn from its axioms, accepted ADRs and named practices. Saying something is anti-PAP means it is completely against the project's established architecture.related: anti-PAP, adr?
Projection (constellation member)
Conceptcomes from ADR · adr-062In the constellation member taxonomy (ADR-062), a member category: one source whose frontier lives INSIDE the build, never its own git repo. A Projection is materialised into each surface that needs it (e.g. assets, examples, docs), synced not cloned — the repo driver is a publication boundary, and a Projection has none of its own. Contrast Primary (owns a boundary → own repo) and Addon (declared edge to a Primary).related: Projection (positioning reveal), Domain (repo_kind CLI extension)Learn more →
Projection (positioning reveal)
Conceptcomes from ADR · adr-057In the reveal architecture (ADR-057), the act of PROJECTING the positioning graph (spine.ncl + generator) onto the outward site: doors generated from a structured contract, a drift fixed by re-running the projection, never by hand-editing the served copy. "The window becomes a projection of a described state, not a construction site." A rendering discipline, not a member category.related: Projection (constellation member)Learn more →
Spiral
Conceptcomes from Tension · ontology-vs-reflectionResolution mode of a Yin/Yang tension where neither pole wins and the system oscillates between them with synthesis emerging from the motion itself. In core.ncl, nodes carry `pole = 'Spiral` when they ARE the tension rather than a position within it. Spirals do not collapse — collapsing one is an antipattern (see colapso-yin-yang).related: Synthesis, Yin/Yang Collapse, Ondaod
Statement of Work (SOW)DRAFT
ArtifactThe terms layer of an Encargo: scope (minimal context + one-sentence objective), a falsifiable contract (a machine check, schema or constraint), and the validation mode ('Machine | 'Adversarial, signed or not). Owned by the human, outside the agent's editable surface — this ownership boundary is what resolves the fox-and-henhouse. One SOW authorizes many Work Orders. Spanish term "Pliego" (as in pliego de prescripciones); the Rust type is `Sow`.related: Encargo (work commission), Work Order (WO), Verified witness
Synthesis
ConceptResolution of a Spiral tension by giving each pole its own plane of operation instead of choosing one. Both poles remain active, applied to different aspects. Synthesis is the productive answer to a Spiral; collapse is the regressive one.related: Spiral, Yin/Yang Collapse, Ondaod
Verified witness
Artifactcomes from ADR · adr-050A content-addressed, Ed25519-signed receipt of an act, deposited at the witness-as-axis seam. It proves *that* a check ran and what it returned — structure, never truthfulness (ADR-050). Necessary but not sufficient as a gate: a witness is post-hoc evidence that X happened, not a barrier that forbids not-X. It becomes a gate only when a control point refuses to proceed without a valid witness (e.g. a commit rejected unless it carries a signed witness that the pre-flight occurred). It is the receipt a Work Order deposits when it completes.related: Work Order (WO), Encargo (work commission), GateLearn more →
Work Order (WO)DRAFT
ArtifactThe execution layer of an Encargo, run under one SOW: disposable, contained, owned by the agent. Carries the deliverable, an observability envelope (workdir, Rust-style log level, JSONL output, start/end timestamps), the verified witness, and a contained verdict ('Accepted | 'Rejected | 'Escalated). A failure dies inside the Work Order rather than contaminating the session. Spanish term "Orden de Trabajo / OT"; the Rust type is `WorkOrder`.related: Encargo (work commission), Statement of Work (SOW), Verified witness
Yin/Yang Collapse
AntipatternAntipattern in which a Spiral tension is forcibly resolved by adopting one pole as 'the answer' and dropping the other. Usually appears as a flip: Yang → Yin (e.g. all-centralized to all-scripted) or vice versa, when the correct move is synthesis — keeping each pole in its proper plane.related: Spiral, Synthesis, Ondaod
adr?
Procedurecomes from Practice · adr-lifecycleEvaluation procedure invoked at the end of a session or feature. Five criteria must all hold to justify an ADR: (1) a meaningful alternative was consciously rejected; (2) lasting constraints for future contributors; (3) reversal needs coordinated multi-component effort; (4) not already captured in an existing ADR; (5) ondaod — engaged tensions identified and synthesis state described. Verdict and rationale are stated concisely; no artifact is created without confirmation.related: Ondaod, PAP
anti-PAP
AntipatternApproach that violates the project's PAP outright. Not 'slightly off' or 'in tension with' — a proposal called anti-PAP is rejected at design time, before implementation.related: PAP
on+re
Practicecomes from Axiom · self-describingShorthand for the Ontoref dual layer: ontology (`.ontology/`: core.ncl, state.ncl, gate.ncl, manifest.ncl — what IS) + reflection (`reflection/`: modes, backlog, constraints, qa — what BECOMES). Every onboarded project instance carries both. A project may host multiple on+re instances at different paths.related: Gate, onre, DAG-Formalized Knowledge
onre
ArtifactShell alias for the `ontoref` CLI. Not a separate binary — invoked as `onre `, equivalent to `ontoref `. `onre` (on+re) replaced the former `ore` alias. Used in documentation and conversation as the operator-facing name.related: on+re
diff --git a/site/site/i18n/locales/en/pages/contact.ftl b/site/site/i18n/locales/en/pages/contact.ftl
index d989a8d..51631e9 100644
--- a/site/site/i18n/locales/en/pages/contact.ftl
+++ b/site/site/i18n/locales/en/pages/contact.ftl
@@ -62,7 +62,6 @@ contact-get-in-touch = Get In Touch
# URLs for navigation
contact-blog-url = /blog
contact-prescriptions-url = /prescriptions
-contact-work-request-url = /work-request
contact-services-url = /services
# Contact form labels and placeholders
@@ -75,3 +74,5 @@ contact-subject-placeholder = Brief description of your inquiry
contact-message-label = Message
contact-message-placeholder = Tell me about your project, goals, timeline, and any specific requirements...
contact-submit-success = Your message has been sent! I'll get back to you within 24 hours.
+
+contact-work-request-url = /work-request
diff --git a/site/site/i18n/locales/en/pages/content_graph.ftl b/site/site/i18n/locales/en/pages/content_graph.ftl
index 865262a..5ab50f9 100644
--- a/site/site/i18n/locales/en/pages/content_graph.ftl
+++ b/site/site/i18n/locales/en/pages/content_graph.ftl
@@ -3,3 +3,8 @@ content-graph-ontology-context = Ontology context
content-graph-title = Knowledge Graph
content-graph-subtitle = An interactive map of all content, ontology nodes, and architectural decisions — and how they connect.
content-graph-hint = Click a node to navigate. Scroll to zoom. Drag to pan. Content nodes link to their page.
+
+# SEO. The key prefix is the route component minus its Page suffix, kebab-cased
+# (ContentGraphPage → content-graph) — see build-config/src/site_config.rs::ftl_page_prefix.
+content-graph-page-title = Knowledge Graph
+content-graph-page-description = An interactive map of all content, ontology nodes, and architectural decisions — and how they connect.
diff --git a/site/site/i18n/locales/en/pages/home.ftl b/site/site/i18n/locales/en/pages/home.ftl
index e4c52c2..908cbc9 100644
--- a/site/site/i18n/locales/en/pages/home.ftl
+++ b/site/site/i18n/locales/en/pages/home.ftl
@@ -8,7 +8,7 @@ home-page-keywords = ontology, reflection, protocol, rust, mcp, nickel, knowledg
# stays hand-maintained. Dead home-hero-* / home-cta-adopt / home-tagline-door-
# {developer,infrastructure,personal} removed 2026-06-20 (template renders spine-*
# and spine-door-*-label instead).
-home-hero-badge = Operational ontology, with reflection · v0.1.7
+home-hero-badge = Operational ontology, with reflection · v0.1.8
# Hero tagline rotator — only the 'all' door label is hand-maintained here.
home-tagline-door-all = All
@@ -50,11 +50,30 @@ home-how-step3-desc = Start the daemon for HTTP UI and MCP. Configure via ~/.con
# Architecture
home-arch-title = Architecture
home-arch-img-light = /images/ontoref-architecture.svg
-home-arch-img-dark = /images/projects/ontoref_architecture-dark.svg
home-arch-caption = Protocol layers — entry point → declarative NCL → operational Nushell → optional Rust runtime. Each layer is independently testable.
+# The SVG is the hook: it shows the layers and their live counts, but the 171 edges it declares are
+# a number inside a box — it draws 5 arrows. The graph draws all of them. This is the line the hook
+# was missing (ADR-057 hook-static / prize-live, route-to-live-graph).
+# The target is NOT invented here: it is the `live_view` declared in .ontoref/positioning/about.ncl,
+# the same one /about's graph block routes to. One source, two surfaces.
+home-arch-live-href = /images/ontoref-graph.html
+home-arch-live-label = Explore the live graph — 60 nodes, 171 edges →
# CTA
home-cta-title = Structure Your Project's Knowledge
home-cta-desc = Install the CLI, run ontoref setup, and your project gains machine-queryable invariants, living ADRs, actor-aware operational modes, and optional daemon context sharing.
home-cta-primary = Get Started
home-cta-secondary = Read the Protocol
+
+# CTA destinations. They are KEYS, not literals in the template: /about is /acerca-de in Spanish,
+# and a hardcoded href would send every Spanish reader to the English URL. Both primary CTAs used to
+# point at /blog — "explore the protocol" delivered a list of posts.
+home-cta-explore-url = /about
+home-cta-primary-url = /about
+home-cta-secondary-url = /blog
+
+# Alt text for the hero illustration. It is NOT a repeat of the headline — the headline is now
+# live text in the
above it. What this alt must carry is the only text left inside the
+# raster: the four value labels baked around the octagon. They exist nowhere else in the
+# codebase, so without this line they are invisible to a screen reader and to every crawler.
+home-hero-art-alt = ontoref: a lit path climbing to the ontoref octagon, ringed by four value nodes — Understand before you change · Verify every change · One knowledge for every actor · Tools, agents and CI aligned.
diff --git a/site/site/i18n/locales/en/pages/home_taglines.ftl b/site/site/i18n/locales/en/pages/home_taglines.ftl
new file mode 100644
index 0000000..e8ecd1b
--- /dev/null
+++ b/site/site/i18n/locales/en/pages/home_taglines.ftl
@@ -0,0 +1,4 @@
+# GENERATED from .ontoref/positioning/taglines.ncl by gen-taglines.nu — do not edit by hand.
+# The rotator's idx-0 frame, rendered server-side so the hero does not flash (or, with JS
+# off, sit on) a phrase the rotator was going to replace anyway.
+home-tagline-initial = A project, an infrastructure, a life: are you still going where you said you were going?
diff --git a/site/site/i18n/locales/en/pages/lenguaje.ftl b/site/site/i18n/locales/en/pages/lenguaje.ftl
new file mode 100644
index 0000000..44bb0ef
--- /dev/null
+++ b/site/site/i18n/locales/en/pages/lenguaje.ftl
@@ -0,0 +1,55 @@
+# A note on language — English
+# GENERATED from .ontoref/ontology/registry.ncl by scripts/gen-nota-lenguaje.nu. Do not edit.
+
+lenguaje-page-title = A note on language
+lenguaje-page-subtitle = Why the Spanish pages here say «haz un commit» and not «confirma los cambios»
+lenguaje-page-description = The criterion deciding which term is translated and which is not — declared, versioned, and enforced by CI.
+lenguaje-page-keywords = language, terminology, translation, spanish, glossary
+
+lenguaje-intro = Writing about software in Spanish has no settled convention. No authority dictates it, the big style guides contradict each other at the edges, and every team ends up deciding text by text. So did we. This is what we decided instead.
+
+lenguaje-h-criterio = The criterion
+lenguaje-criterio-lead = A word stays in English for two DIFFERENT reasons. Conflating them is easy, and it is the mistake that made us rewrite this policy from scratch.
+lenguaje-criterio-1-t = One: it is an identifier.
+lenguaje-criterio-1 = It appears verbatim in the command line, in an API, in an error message you are about to paste into a search box. Translating it breaks the REFERENCE: the text reads well and is useless, because you can no longer get from it to the tool. This holds in every language — it is not an opinion about Spanish.
+lenguaje-criterio-2-t = Two: there is no faithful word.
+lenguaje-criterio-2 = No Spanish word carries the concept without displacing it. Translating it breaks the CONCEPT. «Compuerta» sends it to electronics; «puerta» already means something else here; «umbral» loses the typed policy; «punto de control» loses that it BLOCKS. Every candidate looks reasonable and each loses something different. This one IS a claim about Spanish, and in another language it might be false.
+lenguaje-criterio-3 = And if Spanish does have the word, we use it. A term that happens to resemble a directory name is not thereby untranslatable.
+lenguaje-criterio-run = It also settles the question that seemed to have no answer. «How do you say run in Spanish?» has none BECAUSE IT IS NOT A TERM: it is an ordinary English word. But a Run with an id and a log IS an entity, and it stays. We were looking for one translation of two different things; that is why it never turned up.
+
+lenguaje-h-kept = What we do not translate
+lenguaje-kept-lead = These stay in English, and the last column says by which of the two roads.
+lenguaje-th-termino = Term
+lenguaje-th-que-es = What it is
+lenguaje-th-porque-queda = Why it stays
+
+lenguaje-h-rendered = What we do translate
+lenguaje-rendered-lead = Spanish carries the whole concept. There is nothing to preserve.
+lenguaje-th-en-ingles = In English
+lenguaje-th-decimos = We write
+
+lenguaje-h-verbos = The verbs, which are the real problem
+lenguaje-verbos-1 = This is where everyone gets stuck, and the fix is grammatical, not a matter of taste.
+lenguaje-verbos-2 = A borrowed NOUN is harmless: it enters Spanish, picks a gender, and is done.
+lenguaje-verbos-3 = A borrowed VERB must pick a conjugation — and in Spanish that is -ear, which drags a colloquial register in with it. That is why «commitear» grates and «commit» does not: it is not the loanword, it is the MORPHOLOGY.
+lenguaje-verbos-4 = The way out is a construction Spanish already uses productively: LIGHT SPANISH VERB + ENGLISH NOUN. «Hacer un commit». Spanish supplies the grammar; the loanword stays a noun and keeps pointing at the artifact.
+lenguaje-th-no-escribimos = We do not write
+lenguaje-th-escribimos = We write
+lenguaje-th-porque = Why
+
+lenguaje-h-friends = And the ones that do not grate — the truly dangerous
+lenguaje-friends-1 = A calque announces itself. A FALSE FRIEND does not: it looks like the right translation, reads fluently, and displaces the meaning unnoticed. «Librería» is a SHOP; the word is «biblioteca». Languages evolve their cognates apart, and that drift is invisible precisely because the word still looks like its source.
+lenguaje-friends-2 = Others are true cognates borrowed from ANOTHER discipline: «compuerta» comes from electronics, and drags a logic-circuit reading into a sentence about state transitions.
+
+lenguaje-h-hablando = Speech is another matter
+lenguaje-hablando-1 = None of the above applies to a conversation. A calque spoken communicates perfectly and is jargon on the page. The policy says exactly that: denied in writing, permitted in the mouth. A rule that pretended otherwise would be lying about how its own authors speak, and nobody obeys a rule that lies to them.
+lenguaje-hablando-2 = A false friend, by contrast, misleads a listener exactly as much as a reader. That one is always flagged.
+lenguaje-hablando-3 = The same goes for pronunciation. Saying «ráuter» inside a Spanish sentence is not ignorance: it is phonological accommodation, and every borrowing language does it.
+
+lenguaje-h-legal = This is not a legal notice
+lenguaje-legal-1 = The page next door is the privacy policy, and it exists because the law compels it. This one does not. This is a STYLE CONTRACT: the right analogy is the licence or the code of conduct — normative, published, versioned, referenced.
+lenguaje-legal-2 = With one difference from either: this one is EXECUTED.
+lenguaje-legal-3 = The tables you just read are not hand-written. They are generated from the same declared file that checks every Spanish text on this site before it ships, and that fails the build if it finds a word that should not be there — or if this page stops matching the rule it claims to explain.
+lenguaje-legal-4 = That a project's language policy is itself a declared, versioned and verified artifact is not bureaucracy. It is the project's thesis applied to itself.
+
+lenguaje-foot = This page is a projection of the project's lexical policy. If it contradicts what you read elsewhere on the site, that is a bug and we want to know.
diff --git a/site/site/i18n/locales/en/pages/ontoref.ftl b/site/site/i18n/locales/en/pages/ontoref.ftl
index d7ddc39..59c5e81 100644
--- a/site/site/i18n/locales/en/pages/ontoref.ftl
+++ b/site/site/i18n/locales/en/pages/ontoref.ftl
@@ -1,7 +1,7 @@
ontoref-adoption-subtitle = ontoref setup wires up any new or existing project — idempotent scaffold with optional auth key bootstrap.
ontoref-adoption-title = Adopt in Any Project
ontoref-architecture-title = Architecture
-ontoref-badge = Protocol + Runtime · v0.1.0
+ontoref-badge = Protocol + Runtime · v0.1.8
ontoref-crates-title = Crates & Tooling
ontoref-cta-explore = Explore the Protocol
ontoref-cta-subtitle = Start with ontoref setup. Your project gains machine-queryable invariants, living ADRs, actor-aware operational modes, and a daemon that shares context across every actor in real time.
diff --git a/site/site/i18n/locales/en/pages/rustelo.ftl b/site/site/i18n/locales/en/pages/rustelo.ftl
index b0d6cba..d268738 100644
--- a/site/site/i18n/locales/en/pages/rustelo.ftl
+++ b/site/site/i18n/locales/en/pages/rustelo.ftl
@@ -74,3 +74,7 @@ rustelo-tech-title = Built on Proven Foundations
# Bottom CTA
rustelo-cta-title = Ready to build with Rust?
rustelo-cta-subtitle = Open source · Self-hosted · Zero unsafe · 100% Rust
+
+# SEO (RusteloPage → rustelo).
+rustelo-page-title = Rustelo — Full-Stack Rust Web Framework
+rustelo-page-description = Modular, type-safe Rust platform built on Leptos and Axum. Configuration-driven architecture with language-agnostic routing, plugin system, and dual-target WASM+native compilation.
diff --git a/site/site/i18n/locales/en/pages/services.ftl b/site/site/i18n/locales/en/pages/services.ftl
index 8e9a48d..a6c79c1 100644
--- a/site/site/i18n/locales/en/pages/services.ftl
+++ b/site/site/i18n/locales/en/pages/services.ftl
@@ -76,7 +76,7 @@ services-tier2-card-desc = Ed25519 witnesses and replay determinism: every chang
# ── CTA ─────────────────────────────────────────────────────────────────────
services-cta-title = Where should you start?
services-cta-desc = Tell us your tier and your stack — we will point to the smallest first step, whether that is a coaching session or a tier-2 engagement.
-services-cta-primary = Start a conversation
-services-cta-primary-url = /contact
+services-cta-primary = Request Services
+services-cta-primary-url = /work-request
services-cta-secondary = See what ontoref is
services-cta-secondary-url = /about
diff --git a/site/site/i18n/locales/en/pages/work_request.ftl b/site/site/i18n/locales/en/pages/work_request.ftl
index ab066e0..79b3f92 100644
--- a/site/site/i18n/locales/en/pages/work_request.ftl
+++ b/site/site/i18n/locales/en/pages/work_request.ftl
@@ -6,7 +6,7 @@ work-request-page-description = Submit a work request for your project
work-request-page-keywords = work, request, consultation, project
# Page Header
-work-request-title = Request a Project Quote
+work-request-title = Request a Service Quote
work-request-subtitle = Let's discuss your project requirements and how I can help you achieve your goals.
work-request-description = Fill out the form below with your project details, and I'll get back to you within 24 hours with a personalized proposal.
@@ -130,7 +130,7 @@ work-request-schedule-call = Schedule Call
work-request-form-action = mailto:hello@ontoref.dev
# Missing keys needed by the component
-work-request-project-type-label = Project Type
+work-request-project-type-label = Service Type
work-request-project-type-placeholder = Select project type
work-request-project-type-new = New Project
work-request-project-type-existing = Existing Project Enhancement
diff --git a/site/site/i18n/locales/es/auth.ftl b/site/site/i18n/locales/es/auth.ftl
index 69c4ec0..e870a3f 100644
--- a/site/site/i18n/locales/es/auth.ftl
+++ b/site/site/i18n/locales/es/auth.ftl
@@ -123,4 +123,8 @@ auth-email-otp-subject = Tu código de verificación
auth-email-otp-title = Tu código de verificación
auth-email-otp-subtitle = Usa este código para iniciar sesión:
auth-email-otp-expire-msg = Este código expira en %minutes% minutos.
-auth-email-otp-ignore-msg = Si no solicitaste esto, puedes ignorar este correo.
\ No newline at end of file
+auth-email-otp-ignore-msg = Si no solicitaste esto, puedes ignorar este correo.
+# SEO de la ruta /login (LoginPage → login). Vive aquí porque aquí viven todas las
+# cadenas de login; Fluent une los ficheros de cada locale en un solo bundle.
+login-page-title = Iniciar Sesión
+login-page-description = Inicia sesión en tu cuenta.
diff --git a/site/site/i18n/locales/es/common.ftl b/site/site/i18n/locales/es/common.ftl
index 8968fd9..85f0bb6 100644
--- a/site/site/i18n/locales/es/common.ftl
+++ b/site/site/i18n/locales/es/common.ftl
@@ -22,3 +22,9 @@ common-spanish = Español
# Visor de imagen
common-expand-image = Ampliar
common-close = Cerrar
+
+# Pie de página. La columna reúne las dos páginas legales y la nota sobre el idioma; esta
+# última no obliga a nada, es un contrato de estilo, así que la columna no puede llamarse
+# "Legal" sin mentir sobre lo que contiene.
+footer-legal-title = Condiciones y estilo
+footer-social-title = Redes Sociales
diff --git a/site/site/i18n/locales/es/pages/about-us.ftl b/site/site/i18n/locales/es/pages/about-us.ftl
index 8fe96f3..e194333 100644
--- a/site/site/i18n/locales/es/pages/about-us.ftl
+++ b/site/site/i18n/locales/es/pages/about-us.ftl
@@ -6,4 +6,25 @@ nav-about-us = Nosotros
# Metadatos de Página
about-us-page-title = Nosotros
about-us-page-subtitle = Las personas y la práctica detrás de Ontoref.
-about-us-page-description = Ontoref es diseñado y mantenido por Jesús Pérez, desarrollador Rust y arquitecto de sistemas de aprovisionamiento con más de tres décadas en software. Nace del trabajo directo con infraestructura auto-hospedada y de código abierto, y de la convicción de que los sistemas deben portar su propio razonamiento: una ontología explícita, decisiones registradas y una reflexión disciplinada. Construimos herramientas pequeñas y soberanas que las organizaciones pueden poseer y controlar de verdad, y compartimos el protocolo y su práctica de forma abierta con una comunidad creciente de colaboradores.
+about-us-page-description = Ontoref lo diseña y lo mantiene Jesús Pérez, desarrollador Rust y arquitecto de sistemas de aprovisionamiento con más de tres décadas en software. No sale de una hoja en blanco: sale de años de trabajo con infraestructura auto-hospedada y de código abierto, y de una convicción que cabe en una frase — un sistema debe portar su propio razonamiento.
+
+# Quién
+about-us-h-quien = Quién está detrás
+about-us-quien-1 = Una persona, y el trabajo abierto de una comunidad que crece. La autoría importa aquí por una razón concreta: cada práctica que el protocolo impone existe porque su ausencia costó algo. Ontoref es el destilado de sistemas reales que derivaron, no un diseño sobre el papel.
+about-us-quien-2 = El oficio es el de siempre — Rust para lo que se ejecuta, Nickel para lo que se declara, Nushell para lo que se orquesta — con la disciplina de quien ha tenido que sostener en producción lo que escribió hace diez años.
+
+# Por qué
+about-us-h-porque = Por qué existe ontoref
+about-us-porque-1 = Porque el conocimiento de un proyecto vive donde nadie puede consultarlo: en la cabeza de quien lo construyó, en un hilo de chat, en un README que ya miente. Cuando esa persona se va — o cuando un agente de IA escribe la mitad del código — no queda nada que responda a la pregunta que importa: ¿por qué esto es así, y qué se rompe si lo cambio?
+about-us-porque-2 = La respuesta de ontoref es declarar el razonamiento: axiomas, tensiones, prácticas, estado y gates como NCL tipado, consultable y verificable. Un protocolo, nunca una dependencia en tiempo de ejecución. Lo que hace, en detalle, está en Acerca de ontoref.
+
+# Cómo
+about-us-h-como = Cómo trabajamos
+about-us-como-1 = Con una regla incómoda: una verificación que nadie ha visto negarse no es una verificación. Antes de confiar en una gate hay que falsificarla — romper a propósito lo que debería detectar, y comprobar que lo nombra. Si sólo la has visto pasar, lo único que sabes es que sabe decir que sí.
+about-us-como-2 = Y con una segunda: los fallos se publican. Cuando algo deriva se levanta expediente — el fallo, su causa raíz y lo que quedó en el repositorio para que no vuelva. Están abiertos, con nombre y fecha, en Expedientes. Las decisiones de arquitectura, con sus restricciones vivas, en ADR.
+about-us-como-3 = No es transparencia como gesto. Un sistema que registra sus propias derivas es un sistema que puede auditar quien no estuvo allí — que es, exactamente, el problema que ontoref intenta resolver.
+
+# Abierto
+about-us-h-abierto = Abierto y soberano
+about-us-abierto-1 = Herramientas pequeñas que una organización puede poseer y controlar de verdad: sin SaaS de por medio, sin rehenes, con el protocolo y su práctica compartidos en abierto. Se entra con un solo fichero NCL y se sube de nivel sólo cuando duele.
+about-us-abierto-2 = Si algo de esto te resuena — o si crees que está equivocado y quieres decirlo — escríbenos.
diff --git a/site/site/i18n/locales/es/pages/conceptos.ftl b/site/site/i18n/locales/es/pages/conceptos.ftl
new file mode 100644
index 0000000..64bba34
--- /dev/null
+++ b/site/site/i18n/locales/es/pages/conceptos.ftl
@@ -0,0 +1,10 @@
+# GENERATED from .ontoref/ontology/glossary.ncl by gen-conceptos.nu — do not edit by hand.
+# One source: the same glossary `ontoref describe term` answers from.
+conceptos-page-title = Conceptos clave — ontoref
+conceptos-page-subtitle = Las palabras que este proyecto usa, y qué significan
+conceptos-page-description = El vocabulario de ontoref: cada concepto definido una sola vez, con su categoría, de dónde nace y con qué otros se relaciona.
+conceptos-page-keywords = glosario, conceptos, ontología, reflexión, ADR, ondaod, espiral, síntesis
+conceptos-intro = Este glosario no está escrito aquí. Se proyecta de .ontoref/ontology/glossary.ncl — el mismo fichero del que responde «ontoref describe term» en la terminal. Si una definición cambia, cambia en un sitio y cambia en los dos.
+conceptos-more = Más información →
+conceptos-count = 20
+conceptos-html =
Colapso Yin/Yang
AntipatrónAntipatrón consistente en resolver forzosamente una tensión en Espiral adoptando un polo como 'la respuesta' y descartando el otro. Suele manifestarse como un flip: Yang → Yin (p. ej. todo-centralizado a todo-scripted) o viceversa, cuando lo correcto es la síntesis — mantener cada polo en su plano apropiado.relacionados: Espiral, Síntesis, Ondaod
Conocimiento formalizado como DAG
Conceptonace de Axioma · dag-formalizedAxioma del proyecto: todo el conocimiento — conceptos, tensiones, decisiones, estado — se formaliza como grafos dirigidos acíclicos. Habilita consultas transversales, análisis de impacto y visibilidad a nivel de ecosistema. La grafía 'dao-formalized' que aparece a veces en conversación es folclore para el mismo axioma.relacionados: on+re
Dominio (extensión CLI por repo_kind)
Conceptonace de ADR · adr-064Una extensión CLI activada por repo_kind bajo code/domains/{"{"}id{"}"}/: el repo_kind de un proyecto enciende su dominio, dando comandos conscientes del tipo de proyecto (p. ej. DD7pasos→knowledge-works, DevWorkspace→provisioning). TODOS los code/domains/* son dominios. `schema_cmd` nombra DÓNDE vive el esquema de un dominio (en ontoref vs el proyecto implementador) — es un campo de ubicación de esquema, NO federación.relacionados: Puerta (entrada de embudo), Projection (miembro de constelación)Más información →
EncargoBORRADOR
PrácticaParaguas de la unidad de gobierno que constriñe a un agente comprobando el entregable contra términos explícitos en vez de fiarse del operario. Un Encargo = un Pliego (los términos) + sus Órdenes de Trabajo (las ejecuciones). Dos reglas atómicas lo vuelven hábito: (1) sin alcance y contrato, no se empieza; (2) sin testigo, no está hecho. Cada elemento mata un fallo concreto: el alcance mínimo mata la deriva, el contrato refutable mata la prosa sin verificar, el testigo mata el "fíate de mi palabra", la propiedad externa mata lo de poner al lobo a cuidar las ovejas, el veredicto acotado mata la propagación de código roto.relacionados: Pliego, Orden de Trabajo (OT), Testigo verificado, Gate
Espiral
Conceptonace de Tensión · ontology-vs-reflectionForma de resolución de una tensión Yin/Yang en la que ningún polo gana y el sistema oscila entre ellos, con la síntesis emergiendo del propio movimiento. En core.ncl los nodos llevan `pole = 'Spiral` cuando SON la tensión en lugar de una posición dentro de ella. Las Espirales no se colapsan — colapsar una es un antipatrón (ver colapso-yin-yang).relacionados: Síntesis, Colapso Yin/Yang, Ondaod
Gate
Artefactonace de Esquema · ontology/schemas/gate.nclPrerrequisitos tipados y políticas que controlan las transiciones de estado de la máquina de estados de un proyecto. Vive en `.ontology/gate.ncl`. Cada dimensión declara las condiciones que una transición debe satisfacer (catalizadores presentes, bloqueos despejados); la capa de reflexión evalúa la gate antes de permitir un cambio de estado.relacionados: on+re
Ondaod
Disciplinanace de Tensión · ontology-vs-reflectionDisciplina Dao de Ontoref. Antes de cualquier análisis arquitectónico o redacción de ADR, lee las tensiones nombradas en core.ncl, identifica cuáles activa la pregunta y describe el estado de síntesis y la dirección del movimiento — sin colapsar la Espiral eligiendo un polo. Contenido canónico en dos capas vía el CLI instalado: `ontoref qa show ontoref-dao-discipline --format json` para la línea base del protocolo, y `ontoref qa show -dao-discipline --format json` para extensiones específicas del proyecto.relacionados: Espiral, Síntesis, Colapso Yin/Yang, adr?
Orden de Trabajo (OT)BORRADOR
ArtefactoLa capa de ejecución de un Encargo, ejecutada bajo un Pliego: prescindible, acotada, propiedad del agente. Lleva el entregable, una envoltura de observabilidad (directorio de trabajo, nivel de registro al estilo Rust, salida en JSONL, marcas de inicio y fin), el testigo verificado y un veredicto acotado ('Aceptado | 'Rechazado | 'Escalado). Un fallo muere dentro de la Orden de Trabajo en vez de contaminar la sesión. En código Rust el tipo es `WorkOrder`.relacionados: Encargo, Pliego, Testigo verificado
PAP
Conceptonace de Axioma · self-describingProject's Architecture Principles (Principios de Arquitectura del Proyecto). Conjunto activo de invariantes, patrones y reglas que definen cómo se construye un proyecto concreto — derivado de sus axiomas, ADRs aceptados y prácticas nombradas. Decir que algo es anti-PAP significa que va completamente en contra de la arquitectura establecida.relacionados: anti-PAP, adr?
Patrón de Extensión del Glosario
Prácticanace de Axioma · no-enforcementHerencia en tres niveles para vocabulario: una semilla de protocolo en `reflection/defaults/glossary.ncl` que ontoref distribuye; términos de proyecto añadidos en `.ontology/glossary.ncl::project_terms` vía `d.seed_terms @ project_terms`; división opcional por dominio en `.ontology/glossary/.ncl` cuando el proyecto pasa de ~30 términos. Sin fusión ni copia de la semilla al proyecto — herencia por import. Editar la semilla de protocolo en local está prohibido; redefinir un id de protocolo localmente lo detecta el hook de deriva. Enlaza términos locales con los del protocolo vía `related_terms` para tejer el léxico entre niveles.relacionados: on+re, Ondaod, PAP, Conocimiento formalizado como DAG
PliegoBORRADOR
ArtefactoLa capa de términos de un Encargo: alcance (contexto mínimo + objetivo en una frase), un contrato refutable (una comprobación de máquina, esquema o restricción) y el modo de validación ('Maquina | 'Adversario, firmado o no). Lo posee la persona, fuera de lo que el agente puede editar — esa frontera de propiedad es lo que evita poner al lobo a cuidar las ovejas. Un Pliego autoriza muchas Órdenes de Trabajo. En código Rust el tipo es `Sow`.relacionados: Encargo, Orden de Trabajo (OT), Testigo verificado
Projection (miembro de constelación)
Conceptonace de ADR · adr-062En la taxonomía de miembros de la constelación (ADR-062), una categoría de miembro: una sola fuente cuya frontera vive DENTRO del build, nunca su propio repo git. Un Projection se materializa en cada superficie que lo necesita (assets, examples, docs), sincronizado no clonado — el driver de repo es una frontera de publicación, y un Projection no tiene ninguna propia. Contrasta con Primary (posee frontera → repo propio) y Addon (arista declarada a un Primary).relacionados: Projection (revelado de posicionamiento), Dominio (extensión CLI por repo_kind)Más información →
Projection (revelado de posicionamiento)
Conceptonace de ADR · adr-057En la arquitectura de revelado (ADR-057), el acto de PROYECTAR el grafo de posicionamiento (spine.ncl + generador) sobre el site externo: puertas generadas desde un contrato estructurado, una deriva se arregla re-ejecutando la proyección, nunca editando a mano la copia servida. "La ventana se vuelve la proyección de un estado descrito, no una obra en construcción." Una disciplina de render, no una categoría de miembro.relacionados: Projection (miembro de constelación)Más información →
Puerta (entrada de embudo)
Conceptonace de ADR · adr-064Una de las entradas del embudo externo proyectadas desde spine.ncl (ADR-057/064): developer / infrastructure / authoring / personal. Una puerta es un gancho de enrutado orientado a AUDIENCIA que lleva un `tag` de contenido (p. ej. developer, knowledge-works) y rutea a contenido real, nunca argumenta el core. ADR-064 fija CUATRO puertas — un eje distinto de los CINCO dominios y de la ÚNICA membrana de convergencia.relacionados: Dominio (extensión CLI por repo_kind), Projection (revelado de posicionamiento)Más información →
Síntesis
ConceptoResolución de una tensión en Espiral asignando a cada polo su propio plano de operación en lugar de elegir uno. Ambos polos permanecen activos, aplicados a aspectos distintos. La síntesis es la respuesta productiva a una Espiral; el colapso es la regresiva.relacionados: Espiral, Colapso Yin/Yang, Ondaod
Testigo verificado
Artefactonace de ADR · adr-050Acta de un acto, direccionada por contenido y firmada con Ed25519, depositada en la costura witness-as-axis. Demuestra *que* una comprobación se ejecutó y qué devolvió — estructura, nunca veracidad (ADR-050). Necesaria pero no suficiente como barrera: el testigo es evidencia posterior de que X ocurrió, no una gate que impida no-X. Solo se vuelve gate cuando un punto de control se niega a continuar sin un testigo válido (p. ej. un commit rechazado salvo que lleve un testigo firmado de que la verificación previa ocurrió). Es el acta que deposita una Orden de Trabajo al completarse.relacionados: Orden de Trabajo (OT), Encargo, GateMás información →
adr?
Procedimientonace de Práctica · adr-lifecycleProcedimiento de evaluación que se invoca al final de una sesión o feature. Los cinco criterios deben cumplirse para justificar un ADR: (1) se rechazó conscientemente una alternativa significativa; (2) deja restricciones duraderas para futuros contribuidores; (3) revertirla exige esfuerzo coordinado multi-componente; (4) no está ya capturada en un ADR existente; (5) ondaod — tensiones activadas identificadas y estado de síntesis descrito. Se da el veredicto y la justificación de forma concisa; nada se crea sin confirmación.relacionados: Ondaod, PAP
anti-PAP
AntipatrónEnfoque que viola frontalmente el PAP del proyecto. No es 'ligeramente desviado' ni 'en tensión con' — una propuesta calificada como anti-PAP se rechaza en diseño, antes de implementar.relacionados: PAP
on+re
Prácticanace de Axioma · self-describingAbreviatura de la doble capa de Ontoref: ontología (`.ontology/`: core.ncl, state.ncl, gate.ncl, manifest.ncl — lo que ES) + reflexión (`reflection/`: modos, cartera de pendientes, restricciones, qa — lo que DEVIENE). Toda instancia incorporada del proyecto contiene ambas. Un proyecto puede alojar varias instancias on+re en rutas distintas.relacionados: Gate, onre, Conocimiento formalizado como DAG
onre
ArtefactoAlias de shell para el CLI `ontoref`. No es un binario aparte — se invoca como `onre `, equivalente a `ontoref `. `onre` (on+re) sustituyó al antiguo alias `ore`. Se usa en documentación y conversación como nombre de cara al operador.relacionados: on+re
diff --git a/site/site/i18n/locales/es/pages/contact.ftl b/site/site/i18n/locales/es/pages/contact.ftl
index 35e2e93..dee9945 100644
--- a/site/site/i18n/locales/es/pages/contact.ftl
+++ b/site/site/i18n/locales/es/pages/contact.ftl
@@ -62,7 +62,6 @@ contact-get-in-touch = Ponte en Contacto
# URLs para navegación
contact-blog-url = /blog
contact-prescriptions-url = /prescripciones
-contact-work-request-url = /solicitud-trabajo
contact-services-url = /servicios
# Etiquetas y marcadores de posición del formulario de contacto
@@ -75,3 +74,5 @@ contact-subject-placeholder = Breve descripción de tu consulta
contact-message-label = Mensaje
contact-message-placeholder = Cuéntame sobre tu proyecto, objetivos, cronograma, y cualquier requisito específico...
contact-submit-success = ¡Tu mensaje ha sido enviado\! Me pondré en contacto contigo en 24 horas.
+
+contact-work-request-url = /solicitud-trabajo
diff --git a/site/site/i18n/locales/es/pages/content_graph.ftl b/site/site/i18n/locales/es/pages/content_graph.ftl
index 72cdfb8..4eaa7fe 100644
--- a/site/site/i18n/locales/es/pages/content_graph.ftl
+++ b/site/site/i18n/locales/es/pages/content_graph.ftl
@@ -3,3 +3,8 @@ content-graph-ontology-context = Contexto ontológico
content-graph-title = Grafo de Conocimiento
content-graph-subtitle = Un mapa interactivo de todo el contenido, nodos ontológicos y decisiones arquitectónicas — y cómo se conectan.
content-graph-hint = Haz clic en un nodo para navegar. Desplázate para hacer zoom. Arrastra para mover. Los nodos de contenido enlazan a su página.
+
+# SEO. El prefijo de clave es el componente de ruta sin su sufijo Page, en kebab-case
+# (ContentGraphPage → content-graph) — ver build-config/src/site_config.rs::ftl_page_prefix.
+content-graph-page-title = Grafo de Conocimiento
+content-graph-page-description = Un mapa interactivo de todo el contenido, nodos ontológicos y decisiones arquitectónicas — y cómo se conectan.
diff --git a/site/site/i18n/locales/es/pages/home.ftl b/site/site/i18n/locales/es/pages/home.ftl
index 5c53ae0..8bb410b 100644
--- a/site/site/i18n/locales/es/pages/home.ftl
+++ b/site/site/i18n/locales/es/pages/home.ftl
@@ -8,7 +8,7 @@ home-page-keywords = ontología, reflexión, protocolo, rust, mcp, nickel, grafo
# se mantiene el badge a mano. Claves muertas home-hero-* / home-cta-adopt /
# home-tagline-door-{developer,infrastructure,personal} eliminadas 2026-06-20
# (la plantilla renderiza spine-* y spine-door-*-label).
-home-hero-badge = Ontología operacional con reflexión · v0.1.7
+home-hero-badge = Ontología operacional con reflexión · v0.1.8
# Rotador de taglines — aquí solo se mantiene la etiqueta de la puerta 'all'.
home-tagline-door-all = Todo
@@ -20,7 +20,7 @@ home-cta-github = Código
# proyecto ES y lo que deja verificable); nunca reifica "el grafo" como el que da
# — ver .coder/2026-06-20-home-positioning-projection.plan.md (ondaod).
home-pillars-title = Lo que puede hacer un proyecto que se conoce
-home-pillars-subtitle = Tres capacidades desde un único substrato tipado — pregunta qué se rompe, comprueba quién lo cambió, alcánzalo desde cualquier actor. Independiente de cualquier runtime.
+home-pillars-subtitle = Tres capacidades desde un único substrato tipado — pregunta qué se rompe, comprueba quién lo cambió, alcánzalo desde cualquier actor. Independiente de cualquier tiempo de ejecución.
home-pillar-impact-label = PREGUNTA ANTES DE TOCAR
home-pillar-impact-title = El radio de impacto, antes del diff
@@ -42,7 +42,7 @@ home-how-step1-title = ontoref setup
home-how-step1-desc = Genera el scaffold de .ontology/ y reflection/ con ficheros NCL tipados. Idempotente — seguro de re-ejecutar tras actualizaciones.
home-how-step2-title = ontoref describe project
-home-how-step2-desc = Consulta la identidad, axiomas, tensiones y estado FSM de tu proyecto desde el terminal. Actor-agnostic — misma salida para developer, agente o CI.
+home-how-step2-desc = Consulta la identidad, axiomas, tensiones y estado de la máquina de estados de tu proyecto desde el terminal. Actor-agnostic — misma salida para developer, agente o CI.
home-how-step3-title = ontoref run start
home-how-step3-desc = Arranca el daemon para UI HTTP y MCP. Configurable via ~/.config/ontoref/config.ncl. El protocolo funciona sin él.
@@ -50,11 +50,31 @@ home-how-step3-desc = Arranca el daemon para UI HTTP y MCP. Configurable via ~/.
# Arquitectura
home-arch-title = Arquitectura
home-arch-img-light = /images/ontoref-architecture.svg
-home-arch-img-dark = /images/projects/ontoref_architecture-dark.svg
-home-arch-caption = Capas del protocolo — entry point → NCL declarativo → Nushell operacional → runtime Rust opcional. Cada capa es testeable de forma independiente.
+home-arch-caption = Capas del protocolo — entry point → NCL declarativo → Nushell operacional → tiempo de ejecución Rust opcional. Cada capa es testeable de forma independiente.
+# El SVG es el gancho: enseña las capas y sus cifras vivas, pero las 171 aristas que declara son
+# un número dentro de una caja — dibuja 5 flechas. El grafo las dibuja todas. Esto es el sedal
+# que le faltaba al anzuelo (ADR-057 hook-static / prize-live, route-to-live-graph).
+# El destino NO se inventa aquí: es el `live_view` que declara .ontoref/positioning/about.ncl,
+# el mismo al que enruta el bloque del grafo de /acerca-de. Una sola fuente, dos superficies.
+home-arch-live-href = /images/ontoref-graph.html
+home-arch-live-label = Explorar el grafo vivo — 60 nodos, 171 aristas →
# CTA
home-cta-title = Estructura el Conocimiento de Tu Proyecto
home-cta-desc = Instala el CLI, ejecuta ontoref setup y tu proyecto gana invariantes consultables por máquina, ADRs vivos, modos operacionales con actor-awareness y compartición opcional de contexto del daemon.
home-cta-primary = Empezar
home-cta-secondary = Leer el Protocolo
+
+# Destinos de los CTA. Son CLAVES, no literales en la plantilla: /about es /acerca-de en español, y
+# un href fijo mandaría a todo lector español a la URL inglesa. Los dos CTA primarios apuntaban a
+# /blog — "explorar el protocolo" entregaba una lista de posts.
+home-cta-explore-url = /acerca-de
+home-cta-primary-url = /acerca-de
+home-cta-secondary-url = /blog
+
+# Texto alternativo de la ilustración del hero. NO repite el titular — el titular ya es texto
+# vivo en el
de encima. Lo que este alt tiene que rescatar es el único texto que queda
+# dentro del ráster: las cuatro etiquetas de valor pintadas alrededor del octógono. No existen
+# en ninguna otra parte del código, así que sin esta línea son invisibles para un lector de
+# pantalla y para cualquier rastreador.
+home-hero-art-alt = ontoref: un sendero iluminado que asciende hasta el octógono de ontoref, rodeado de cuatro nodos de valor — Entiende antes de cambiar · Verifica cada cambio · Un conocimiento para cada actor · Herramientas, agentes y CI alineados.
diff --git a/site/site/i18n/locales/es/pages/home_spine.ftl b/site/site/i18n/locales/es/pages/home_spine.ftl
index 00d9c82..506193e 100644
--- a/site/site/i18n/locales/es/pages/home_spine.ftl
+++ b/site/site/i18n/locales/es/pages/home_spine.ftl
@@ -1,5 +1,5 @@
# GENERATED from .ontoref/positioning/spine.ncl by gen-spine-pages.nu — do not edit by hand.
-spine-hero = Pisa firme y anda ligero.
+spine-hero = Pisa firme, con paso ligero.
spine-sub = Tu proyecto, tu infra, tu obra, tu vida: ¿sigues yendo a donde dijiste?
spine-close = Lo que dejas dicho, alguien podrá comprobarlo.
spine-prize = Cuando tu razón de ser es verificable y no solo declarada, mantener el rumbo deja de costar esfuerzo.
diff --git a/site/site/i18n/locales/es/pages/home_taglines.ftl b/site/site/i18n/locales/es/pages/home_taglines.ftl
new file mode 100644
index 0000000..ae46549
--- /dev/null
+++ b/site/site/i18n/locales/es/pages/home_taglines.ftl
@@ -0,0 +1,4 @@
+# GENERATED from .ontoref/positioning/taglines.ncl by gen-taglines.nu — do not edit by hand.
+# The rotator's idx-0 frame, rendered server-side so the hero does not flash (or, with JS
+# off, sit on) a phrase the rotator was going to replace anyway.
+home-tagline-initial = Un proyecto, una infraestructura, una vida: ¿sigues yendo a donde dijiste que ibas?
diff --git a/site/site/i18n/locales/es/pages/lenguaje.ftl b/site/site/i18n/locales/es/pages/lenguaje.ftl
new file mode 100644
index 0000000..5fb7708
--- /dev/null
+++ b/site/site/i18n/locales/es/pages/lenguaje.ftl
@@ -0,0 +1,56 @@
+# Nota sobre el lenguaje — español
+# GENERADO desde .ontoref/ontology/registry.ncl por scripts/gen-nota-lenguaje.nu.
+# NO EDITAR A MANO: la próxima regeneración lo sobrescribe, y `--check` rompe el build si diverge.
+
+lenguaje-page-title = Nota sobre el lenguaje
+lenguaje-page-subtitle = Por qué este sitio dice «haz un commit» y no «confirma los cambios»
+lenguaje-page-description = El criterio con el que decidimos qué término se traduce y cuál no — declarado, versionado y verificado por CI.
+lenguaje-page-keywords = lenguaje, terminología, traducción, español, glosario
+
+lenguaje-intro = Escribir sobre software en español no tiene convención asentada. No hay una autoridad que lo dicte, las guías de estilo de las grandes empresas se contradicen en los bordes, y cada equipo acaba resolviéndolo texto a texto. Nosotros también lo hacíamos así. Esto es lo que decidimos en su lugar.
+
+lenguaje-h-criterio = El criterio
+lenguaje-criterio-lead = Una palabra se queda en inglés por dos motivos distintos. Confundirlos es fácil, y es el error que nos hizo reescribir esta política entera.
+lenguaje-criterio-1-t = Uno: es un identificador.
+lenguaje-criterio-1 = Aparece tal cual en la línea de comandos, en una API, en un mensaje de error que vas a pegar en un buscador. Traducirlo rompe la referencia: el texto se lee bien y ya no te sirve para nada, porque no puedes volver de él a la herramienta. Vale para cualquier idioma — no es una opinión sobre el español.
+lenguaje-criterio-2-t = Dos: no hay palabra fiel.
+lenguaje-criterio-2 = Ninguna palabra española carga el concepto sin desplazarlo. Traducirlo rompe el concepto. «Compuerta» lo manda a la electrónica; «puerta» ya significa otra cosa aquí; «umbral» pierde que es una condición tipada; «punto de control» pierde que bloquea. Cada candidato parece razonable y cada uno pierde algo distinto. Esto sí es una afirmación sobre el español, y en otro idioma podría ser falsa.
+lenguaje-criterio-3 = Y si el español sí tiene la palabra, la usamos. Sin complejos y sin nostalgia. Que un término se parezca al nombre de un fichero no lo vuelve intraducible.
+lenguaje-criterio-run = Eso resuelve, de paso, la pregunta que parecía no tener respuesta. «¿Cómo se dice run en español?» no la tiene porque no es un término: es una palabra inglesa cualquiera, y según la frase será ejecutar, una ejecución o una pasada. Pero un Run con su identificador y su registro sí es una entidad, y se queda. Buscábamos una traducción para dos cosas distintas; por eso no aparecía.
+
+lenguaje-h-kept = Lo que no traducimos
+lenguaje-kept-lead = Se quedan en inglés, y la última columna dice por cuál de los dos motivos.
+lenguaje-th-termino = Término
+lenguaje-th-que-es = Qué es
+lenguaje-th-porque-queda = Por qué se queda
+
+lenguaje-h-rendered = Lo que sí traducimos
+lenguaje-rendered-lead = El español carga el concepto entero. No hay nada que preservar.
+lenguaje-th-en-ingles = En inglés
+lenguaje-th-decimos = Aquí decimos
+
+lenguaje-h-verbos = Los verbos, que son el problema de verdad
+lenguaje-verbos-1 = Aquí es donde todo el mundo se atasca, y la solución no es cuestión de gusto sino de gramática.
+lenguaje-verbos-2 = Un préstamo sustantivo es inofensivo: entra en español, elige género y ya está. El commit. La branch. No negocia nada más.
+lenguaje-verbos-3 = Un préstamo verbo, en cambio, está obligado a elegir conjugación — y en español acaba casi siempre en -ear, que arrastra un registro coloquial. Por eso «commitear» chirría y «commit» no: no es el anglicismo, es la morfología. Le estás pidiendo a la palabra inglesa que se conjugue, y eso la marca.
+lenguaje-verbos-4 = La salida es una construcción que el español ya usa de forma productiva (hacer clic, hacer una copia): verbo español + sustantivo inglés. Hacer un commit. Abrir un Pull Request. Aplicar un rebase. El español pone la gramática; el préstamo se queda quieto, señalando al artefacto.
+lenguaje-th-no-escribimos = No escribimos
+lenguaje-th-escribimos = Escribimos
+lenguaje-th-porque = Por qué
+
+lenguaje-h-friends = Y los que no chirrían — los peligrosos de verdad
+lenguaje-friends-1 = Un calco se oye venir. Un falso amigo no: parece la traducción correcta, se lee con fluidez, y desplaza el significado sin que nadie lo note. «Librería» es una tienda; la palabra que buscas es biblioteca. Cada lengua evoluciona sus cognados por su cuenta, y esa deriva es invisible precisamente porque la palabra sigue pareciéndose a su origen.
+lenguaje-friends-2 = Otros son cognados de verdad, pero tomados de otra disciplina: «compuerta» viene de la electrónica, y mete la lectura de circuito en una frase que hablaba de transiciones de estado.
+
+lenguaje-h-hablando = Hablando es otra cosa
+lenguaje-hablando-1 = Nada de lo anterior se aplica a una conversación. «Commiteé y luego mergeé» comunica perfectamente entre quienes trabajan con esto, y escrito sería jerga. La política dice exactamente eso: el calco está prohibido en todo texto y permitido en la boca. Una regla que fingiera lo contrario estaría mintiendo sobre cómo hablamos, y una regla que miente no la cumple nadie.
+lenguaje-hablando-2 = Un falso amigo, en cambio, engaña igual a quien escucha que a quien lee. Ése se avisa siempre.
+lenguaje-hablando-3 = Lo mismo vale para la pronunciación. Decir ráuter o dóker dentro de una frase en español no es ignorancia: es acomodación fonológica, y la hacen todas las lenguas que reciben préstamos. Pronunciar el término con fonética inglesa nativa en mitad de una frase en español es la opción marcada — por eso suena a presunción y no a precisión.
+
+lenguaje-h-legal = Esto no es un aviso legal
+lenguaje-legal-1 = La página de al lado es la política de privacidad, y existe porque la ley obliga. Ésta no. Ésta es un contrato de estilo: la analogía correcta no es el aviso legal, sino la licencia o el código de conducta — un documento normativo, publicado, versionado y referenciado.
+lenguaje-legal-2 = Con una diferencia respecto a esos dos: éste se ejecuta.
+lenguaje-legal-3 = Las tablas que acabas de leer no están escritas a mano. Se generan desde el mismo fichero declarado que revisa cada texto en español de este sitio antes de publicarlo, y que falla la compilación si encuentra una palabra que no debería estar — o si esta página deja de coincidir con la regla que dice explicar.
+lenguaje-legal-4 = Que la política lingüística de un proyecto sea a su vez un artefacto declarado, versionado y verificado no es burocracia. Es la tesis del proyecto aplicada a sí misma.
+
+lenguaje-foot = Esta página es una proyección de la política léxica del proyecto. Si encuentras una incoherencia entre lo que dice y lo que lees en el resto del sitio, es un fallo y nos interesa.
diff --git a/site/site/i18n/locales/es/pages/ontoref.ftl b/site/site/i18n/locales/es/pages/ontoref.ftl
index a3ea8d7..c1f9e37 100644
--- a/site/site/i18n/locales/es/pages/ontoref.ftl
+++ b/site/site/i18n/locales/es/pages/ontoref.ftl
@@ -1,7 +1,7 @@
ontoref-adoption-subtitle = ontoref setup conecta cualquier proyecto nuevo o existente — scaffold idempotente con bootstrap de auth keys opcional.
ontoref-adoption-title = Adoptar en Cualquier Proyecto
ontoref-architecture-title = Arquitectura
-ontoref-badge = Protocolo + Runtime · v0.1.0
+ontoref-badge = Protocolo + Runtime · v0.1.8
ontoref-crates-title = Crates y Herramientas
ontoref-cta-explore = Explorar el Protocolo
ontoref-cta-subtitle = Empieza con ontoref setup. Tu proyecto gana invariantes consultables por máquina, ADRs vivos, modos operacionales con actor-awareness y un daemon que comparte contexto entre todos los actores en tiempo real.
@@ -11,11 +11,11 @@ ontoref-footer-tagline = Protocolo + Runtime. Sin coacción. Un grafo por proyec
ontoref-graph-desc = Grafo dirigido por fuerzas de la ontología en vivo. Los nodos son tipados (Axioma · Tensión · Práctica) y polarizados (Yang · Yin · Espiral). Haz clic en cualquier nodo para abrir su panel de detalles.
ontoref-graph-title = La UI en Acción -> Vista de Grafo
ontoref-hero-coda = Protocolo + Runtime. Sin coacción.
-ontoref-hero-desc = — codifica lo que un sistema ES (invariantes, tensiones, constraints) y hacia dónde VA (dimensiones de estado, condiciones de transición, membranas) en grafos acíclicos dirigidos consultables por máquina. Proyectos de software, sistemas operacionales personales, contextos de agente — los mismos tres ficheros, el mismo protocolo. Pregunta el radio de impacto de un cambio antes de hacerlo, verifica cada mutación contra las claves del actor, comparte un único contexto tipado en vivo entre CLI, IDE y CI. Un protocolo para desarrolladores, agentes, CI e individuos.
+ontoref-hero-desc = — codifica lo que un sistema ES (invariantes, tensiones, restricciones) y hacia dónde VA (dimensiones de estado, condiciones de transición, membranas) en grafos acíclicos dirigidos consultables por máquina. Proyectos de software, sistemas operacionales personales, contextos de agente — los mismos tres ficheros, el mismo protocolo. Pregunta el radio de impacto de un cambio antes de hacerlo, verifica cada mutación contra las claves del actor, comparte un único contexto tipado en vivo entre CLI, IDE y CI. Un protocolo para desarrolladores, agentes, CI e individuos.
ontoref-hero-highlight = Ontología + Reflexión + Daemon + MCP
ontoref-layer-adopt-desc = Cada proyecto mantiene sus propios datos de .ontology/. Ontoref provee los schemas, módulos y scripts de migración. Cero vendor lock-in.
ontoref-layer-adopt-label = CAPA DE ADOPCION · Por proyecto
-ontoref-layer-decl-desc = Tipos fuertes, contratos, enums. Falla en definición, no en runtime.
+ontoref-layer-decl-desc = Tipos fuertes, contratos, enums. Falla en definición, no en tiempo de ejecución.
ontoref-layer-decl-label = CAPA DECLARATIVA · Nickel
ontoref-layer-entry-desc = Un único entry point por proyecto. Detecta actor (developer/agent/CI), adquiere lock, despacha al módulo Nu correcto.
ontoref-layer-entry-label = PUNTO DE ENTRADA · Bash → Nu
@@ -24,11 +24,11 @@ ontoref-layer-graph-label = GRAFO DE CONOCIMIENTO · .ontology/
ontoref-layer-op-desc = Pipelines tipadas sobre datos estructurados. No streams de texto.
ontoref-layer-op-label = CAPA OPERACIONAL · Nushell
ontoref-layer-runtime-desc = Daemon persistente opcional. Caché de exports NCL, UI HTTP, servidor MCP, registro de actores, almacén de notificaciones, motor de búsqueda, persistencia SurrealDB. Nunca un requisito del protocolo.
-ontoref-layer-runtime-label = CAPA RUNTIME · Rust + axum
-ontoref-mcp-backlog-desc =
pre_commit — el hook pre-commit hace POLL en GET /notifications/pending?token=X&project=Y; bloquea el commit git hasta que todo es reconocido
drift — drift de schema detectado entre codebase y ontología
ontology_drift — emitido por el observador pasivo con conteos missing/stale/drift/broken tras 15s debounce
Fail-open: si el daemon no está disponible, el hook pre-commit pasa — los commits nunca son bloqueados por caída del daemon
Ack vía UI o POST /notifications/ack; notificaciones custom vía POST /{slug}/notifications/emit
Los botones de acción en notificaciones pueden enlazar a cualquier página del dashboard
pre_commit — el hook pre-commit hace POLL en GET /notifications/pending?token=X&project=Y; bloquea el commit git hasta que todo es reconocido
drift — deriva de esquema detectada entre codebase y ontología
ontology_drift — emitido por el observador pasivo con conteos missing/stale/drift/broken tras 15s debounce
Fail-open: si el daemon no está disponible, el hook pre-commit pasa — los commits nunca son bloqueados por caída del daemon
Ack vía UI o POST /notifications/ack; notificaciones custom vía POST /{slug}/notifications/emit
Los botones de acción en notificaciones pueden enlazar a cualquier página del dashboard
ontoref-mcp-backlog-title = Barrera de Notificaciones
ontoref-mcp-core-desc = ontoref-daemon es un proceso persistente opcional. Cachea exports NCL, sirve la UI web, expone la superficie de herramientas MCP, mantiene un registro de actores, almacena notificaciones, indexa todo para búsqueda y opcionalmente persiste en SurrealDB. Auth es opt-in: todas las superficies (CLI, UI, MCP) intercambian una project key por un token de sesión UUID v4 via POST /sessions; la CLI inyecta ONTOREF_TOKEN como Bearer automáticamente. Nunca cambia el protocolo — acelera y comparte el acceso a él. Configurado via ~/.config/ontoref/config.ncl (Nickel, type-checked); edición interactiva con ontoref config-edit. Iniciado via NCL pipe bootstrap: ontoref-daemon-boot.
-ontoref-mcp-knowledge-desc =
Habilitado con flag de feature --db y --db-url ws://...
Conecta vía WebSocket al inicio — 5s timeout, fail-open (el daemon funciona sin él)
Siembra tablas de ontología desde archivos NCL locales al inicio y en cambios de fichero
Persiste: sesiones de actores, tablas de ontología sembradas, índice de búsqueda, historial de notificaciones
Sin --db: respaldado por DashMap en memoria, solo durante el proceso
ontoref-mcp-knowledge-title = Persistencia SurrealDB — Opcional
ontoref-mcp-query-title = El Servidor MCP — Acceso al DAG para Agentes
ontoref-mcp-table-desc-header = Descripción
@@ -36,19 +36,19 @@ ontoref-mcp-table-tool-header = Herramienta
ontoref-mcp-title = Daemon & MCP — Capa de Inteligencia en Tiempo de Ejecución
ontoref-mcp-tool-action-add-desc = Crear modo de reflexión + registrar como acción rápida
ontoref-mcp-tool-action-list-desc = Catálogo de acciones rápidas de .ontoref/config.ncl
-ontoref-mcp-tool-backlog-desc = Añadir o actualizar estado de elemento del backlog
-ontoref-mcp-tool-constraints-desc = Todos los constraints arquitectónicos hard + soft
+ontoref-mcp-tool-backlog-desc = Añadir o actualizar estado de un elemento de la cartera de pendientes
+ontoref-mcp-tool-constraints-desc = Todas las restricciones arquitectónicas hard + soft
ontoref-mcp-tool-describe-desc = Resumen de arquitectura y auto-descripción
-ontoref-mcp-tool-get-adr-desc = Contenido completo de ADR con constraints
-ontoref-mcp-tool-get-backlog-desc = Elementos de backlog filtrados por estado
+ontoref-mcp-tool-get-adr-desc = Contenido completo de ADR con restricciones
+ontoref-mcp-tool-get-backlog-desc = Elementos de la cartera de pendientes filtrados por estado
ontoref-mcp-tool-get-desc = Obtener nodo de ontología por id
ontoref-mcp-tool-get-mode-desc = Contrato DAG del modo — pasos, pre/postcondiciones
-ontoref-mcp-tool-get-node-desc = Nodo completo con aristas y constraints
+ontoref-mcp-tool-get-node-desc = Nodo completo con aristas y restricciones
ontoref-mcp-tool-help-desc = Lista herramientas disponibles y uso
ontoref-mcp-tool-list-adrs-desc = Listar ADRs filtrados por estado
ontoref-mcp-tool-list-modes-desc = Listar todos los modos de reflexión
ontoref-mcp-tool-list-projects-desc = Enumerar todos los proyectos registrados
-ontoref-mcp-tool-project-status-desc = Dashboard completo del proyecto — salud, drift, actores
+ontoref-mcp-tool-project-status-desc = Dashboard completo del proyecto — salud, deriva, actores
ontoref-mcp-tool-qa-add-desc = Persistir nueva entrada Q&A en reflection/qa.ncl
ontoref-mcp-tool-qa-list-desc = Listar almacén Q&A con filtro opcional
ontoref-mcp-tool-search-desc = Búsqueda de texto libre en nodos, ADRs, modos
@@ -56,17 +56,17 @@ ontoref-mcp-tool-set-project-desc = Establecer contexto de proyecto por defecto
ontoref-metrics-title = Métricas del Protocolo
ontoref-page-subtitle = Protocolo Auto-Descriptivo para Sistemas Evolutivos
ontoref-page-title = Ontoref — Un Protocolo de Ontología y Reflexión Auto-Descriptivo
-ontoref-problem-1-desc =
Decisiones arquitectónicas en chat, olvidadas tras rotación
Sin fuente consultable por máquina de por qué algo existe
ADRs como Nickel tipado: invariantes, constraints, cadena de supersedencia
Constraints Hard aplicadas en cada operación
+ontoref-problem-1-desc =
Decisiones arquitectónicas en chat, olvidadas tras rotación
Sin fuente consultable por máquina de por qué algo existe
ADRs como Nickel tipado: invariantes, restricciones, cadena de supersedencia
Restricciones Hard aplicadas en cada operación
ontoref-problem-1-title = Decisiones Sin Memoria
ontoref-problem-2-desc =
Configs cambian fuera de cualquier ciclo de revisión
Sin trazabilidad que vincule cambio a PR o ADR
Rollback requiere arqueología manual de ficheros
Perfiles sellados: hash sha256, historia completa, rollback verificado
-ontoref-problem-2-title = Drift de Configuración Invisible
-ontoref-problem-3-desc =
Los LLMs empiezan cada sesión con cero conocimiento del proyecto
Mismos errores, mismas preguntas, sin acumulación entre operaciones
El registro de actores rastrea cada token de sesión, tipo, modo actual, último visto — persistido en disco
Las herramientas MCP dan a los agentes acceso DAG de lectura/escritura directo: nodos, ADRs, backlog, Q&A
Tareas compuestas compartidas via daemon — múltiples actores ven el mismo contexto operacional en vivo
+ontoref-problem-2-title = Deriva de Configuración Invisible
+ontoref-problem-3-desc =
Los LLMs empiezan cada sesión con cero conocimiento del proyecto
Mismos errores, mismas preguntas, sin acumulación entre operaciones
El registro de actores rastrea cada token de sesión, tipo, modo actual, último visto — persistido en disco
Las herramientas MCP dan a los agentes acceso DAG de lectura/escritura directo: nodos, ADRs, cartera de pendientes, Q&A
Tareas compuestas compartidas via daemon — múltiples actores ven el mismo contexto operacional en vivo
ontoref-problem-3-title = Agentes Sin Contexto
ontoref-problem-4-desc =
Guías en wikis, patrones en docs, decisiones en Slack
Sin fuente única consultable por humanos, agentes y CI por igual
.ontology/ separa tres concerns ortogonales: core.ncl (lo que ES) · state.ncl (dónde ESTAMOS vs queremos estar) · gate.ncl (cuándo LISTO para cruzar una frontera)
reflection/ lee los tres y responde consultas de autoconocimiento — un agente entiende el proyecto sin leer código, solo consultando el grafo declarativo
ontoref-problem-4-title = Conocimiento de Proyecto Disperso
ontoref-problem-5-desc =
Cada proyecto reinventa sus propias convenciones
Sin contrato compartido para cómo se definen y ejecutan las operaciones
Modos de reflexión: contratos DAG tipados para cualquier flujo
Un protocolo adoptado por proyecto, sin imponer uniformidad
ontoref-problem-5-title = Fragmentación de Protocolo
-ontoref-problem-6-desc =
Q&A respondido en una sesión olvidado en la siguiente
El agente repite preguntas ya respondidas en sesiones anteriores
Q&A Knowledge Store: NCL tipado, versionado en git, persiste a través de resets del navegador
La barrera de notificaciones transmite drift a los agentes de forma proactiva — señales pre_commit, drift, ontology_drift bloquean hasta ser reconocidas
+ontoref-problem-6-desc =
Q&A respondido en una sesión olvidado en la siguiente
El agente repite preguntas ya respondidas en sesiones anteriores
Q&A Knowledge Store: NCL tipado, versionado en git, persiste a través de resets del navegador
La barrera de notificaciones transmite deriva a los agentes de forma proactiva — señales pre_commit, drift, ontology_drift bloquean hasta ser reconocidas
ontoref-problem-6-title = Conocimiento Perdido Entre Sesiones
ontoref-problem-7-desc =
Decisiones personales y profesionales tomadas contra supuestos implícitos e inverificables
Sin modelo consultable de lo que nunca comprometes
Sin forma estructurada de preguntar: ¿viola esta oportunidad quién soy?
ontoref como ontología operacional personal — los mismos ficheros core/state/gate aplicados a dimensiones de vida, carrera y ecosistema
ontoref-problem-7-title = Decisiones Sin Mapa
@@ -77,7 +77,7 @@ ontoref-tension-1 = Ontología sin Reflexión = correcta pero estática. Inva
ontoref-tension-2 = Reflexión sin Ontología = fluida pero sin ancla. Flujos que olvidan lo que protegen.
ontoref-tension-thesis = El protocolo vive en la coexistencia.
ontoref-ui-dashboard-title = La UI Web
-ontoref-yang-desc =
Modos — contratos DAG tipados de flujo (precondiciones, pasos, postcondiciones)
Formularios — recolección de parámetros que conducen modos
Ciclo de vida ADR — Proposed → Accepted → Superseded, con historial de constraints
-
-
-
-
-
-
-
-
