The process

Each stage has a review gate and produces ontology-Shape instances. Work in ontology order, not implementation order — but prove everything on one narrow vertical slice early rather than perfecting the model in the abstract.

The worked example throughout: Meridian Engineering, a fictional mid-size AEC firm (water/wastewater, stormwater, geomatics). Meridian’s driving question: which wastewater facilities in our region appear to face increasing treatment-upgrade pressure, and which of their owners should we pursue?

Stage 0 — Charter and commitments

Outcome: a charter a reviewer can use to reject a nonconforming Shape or mapping without further debate. Produces: OntologyCharter/ontology/charter (fixed well-known name — one per repo).

State mission (including whom the ontology serves), non-goals (as load-bearing as goals: not a source-system mirror, not a CRM, not a document store, not a legal-compliance determination engine), and binding commitments. Commitments worth adopting in almost any domain:

• Identity: a source identifier is never silently equated with real-world identity. Before minting an alternative, evaluate whether an established domain authority already defines and stewards the needed identity. Adopt it deliberately when it fits the competency questions; preserve conflicts and require a question-backed benefit before departing from it.
• Epistemic: a source record expresses what a source reported; observation ≠ inferred state; rich interpretation ≠ binomial proposition; absence of evidence ≠ evidence of absence; conflict is knowledge; no generic confidence field.
• Temporal: event time, valid time, source time, and system time are four different clocks; platform version history is system time and never substitutes for domain valid-time fields; ban fields named date.
• Layering: every Thing belongs to exactly one epistemic layer; beliefs are owned and attributed; the observational line is not crossed in organization-neutral layers.

Meridian charters: “represent the observable public infrastructure of our operating region so engineers and agents can discover, compare, and reason about owners, facilities, permits, monitoring, violations, and funding — traceable to sources, reusable across every pursuit.” Non-goal: replacing the state environmental agency’s database, or Meridian’s CRM.

Do not create a charter-only release. The charter, questions, and contracts may be reviewed and revised while the first usable slice is designed. Create Set/ontology/release only at Stage 9, when it can contain the current contract assertions for an ontology that answers at least one reviewed question. Component installation or update is a prerequisite when those records reference component-owned Shape versions; installing a component never creates the project’s ontology release.

Stage 1 — Competency questions

Outcome: a versioned question backlog; every later artifact can cite the questions it serves. Produces: CompetencyQuestion/ontology/{domain}/{id} Things.

The ontology is judged by the questions it answers — nothing else. Interview each persona and collect the questions they actually ask. A broad backlog is useful for preserving scope, but rank questions by commonness × decision value and select a narrow executable release. Shared source or transformation work may influence delivery grouping; available data must not define the ontology boundary. Formalize the selected questions:

CompetencyQuestion/ontology/water/001
  question: "Which wastewater facilities in our region have recurring
             warm-season ammonia excursions in the past five years?"
  personas: [wastewater-process-engineer, market-leader]
  requiredConcepts: [Facility, Permit, Parameter, Measurement, PermitLimit]   # wrefs to Shapes
  temporalSemantics: "rolling 5-year window; seasonality required"
  provenanceRequirement: artifact-hash-level

Then wield them in both directions. The deletion test: every candidate Shape and field must name a question that becomes impossible or materially harder without it — no answer, it doesn’t ship. The change test: every proposed change to an existing repo must name a question the current model cannot answer correctly — no answer, don’t change it.

Questions are also the eval set: each becomes an acceptance test with provenance requirements attached (Stage 9). And expect questions to push back on the model — when working a real question exposes a sloppy concept (“outfall discharges to waterbody” hides that the discharge is an activity and the outfall a point), the process is working.

Existing semantics gate

Before proposing a Shape or canonical identity, research what the domain already means by the concept. For each load-bearing term and identifier, inspect official definitions and data dictionaries, identifier scope and lifecycle, matching and correction behavior, stewardship, crosswalks, and the terminology and workflows used by practitioners. Record the authoritative sources and the date reviewed. A mature registry or master-data system is a candidate identity provider, not merely another raw record source.

Default to alignment or reuse when the established model answers the selected questions correctly. Mint a competing concept only when a named competency question cannot be answered correctly with the established semantics and the measurable benefit outweighs translation, interoperability, stewardship, and adoption costs. A broader definition, source variation, or an internally cleaner alternative is not sufficient evidence. Use adversarial cases to show the actual failure and define any bridge or migration the departure requires.

Meridian collects identity questions (“which source records refer to the same real facility? who owns vs. operates it, now and historically?”), domain questions (“show every normalized ammonia measurement beside its applicable limit”), and belief questions (“which owners fit our profile, and why does the system believe this account warrants outreach?”).

Decision interviews: one consequential question at a time

For a new ontology or material semantic revision, maintain an ordered queue of unresolved decisions that block the selected release. Research factual and source questions first: official definitions and real profiling should settle cardinality, missingness, key stability, status vocabularies, and adversarial cases rather than asking a reviewer to guess. Unless the reviewer asks for a different format, present exactly one consequential question at a time:

Competency question being protected:
Decision to settle:
Why it matters:
Relevant source evidence:
Proposed smallest sufficient answer:
Alternatives deliberately deferred:
Evidence that would reopen the choice:
Do you agree, disagree, or want to modify it?

After the answer, carry its governing principle into later proposals and state:

Accepted decision:
Governing principle:
Durable home:
  - OntologyCharter commitment
  - CompetencyQuestion/acceptance invariant
  - SemanticContract, NamingContract, or PredicateDeclaration
  - OntologyDecision
  - toolkit principle candidate
  - implementation/operational rule outside the ontology

Update or propose the durable artifact before asking the next question; chat history is not the source of truth. Create an OntologyDecision only when a meaningful alternative was considered, the rationale matters to a future maintainer or consumer, the choice could plausibly be revisited, and concrete settling or reopening evidence can be named. Routine field selection, implementation choices, source-profiled facts, and conclusions forced by an accepted charter, contract, or platform invariant do not earn decision Things.

Semantic closure is reached when no unresolved semantic decision blocks the selected release. Stop asking ontology questions then. List implementation work and explicit future-phase deferrals separately; neither should silently expand the ontology.

Stage 2 — Semantic contracts

Outcome: each core type has an identity test and counterexamples a steward can apply to a confusing real record. Produces: SemanticContract/ontology/{type} Assertions, each about the Shape it governs.

Before any Shape gets fields, its concept gets a contract: definition, identity test (when do two records refer to the same one?), examples, counterexamples, lifecycle notes, and status (candidate → experimental → approved → deprecated). The identity test and counterexamples are the heart — most ontology failures are identity failures. Treat familiar distinctions as questions to test against domain authority, not reusable conclusions:

Distinction	Why it matters
Organization vs. Facility	usually distinct because owners change, but verify the adopted authority’s scope
Facility vs. Site	an authority may deliberately identify a facility, site, or place as one governed concept; split it only when a question requires the distinction
Facility vs. InfrastructureSystem	test whether the system and participating works have independent identity and lifecycle
source record vs. canonical Thing	an ordinary program record is evidence; an authority-managed registry identity may deliberately own the canonical anchor after review
observation ≠ inferred state ≠ legal determination	a computed excursion is not a regulator-issued violation

For Meridian’s current questions, EPA’s Facility Registry Service is an established master-data and facility-identification system: it integrates program records under Registry IDs, publishes data standards and crosswalks, and has explicit steward correction processes (FRS description, facility-identification overview). Meridian therefore aligns Facility one-to-one with the reviewed FRS registry identity. It defers a narrower physical-works concept until a competency question demonstrates a benefit that justifies a second identity and its mappings.

Load-bearing external identifiers get contract treatment here (or in the naming contract they drive): when a name, resolution rule, or mapping depends on an external identifier (a permit number, a registry id), record its issuer and semantic scope, normalization, stability/reuse/succession behavior, matching and correction process, stewardship, and authoritative lookup source. State whether the identifier is merely grounding evidence or the deliberately adopted canonical identity. The name built on an identifier is only as stable as the identifier’s own lifecycle.

Stage 3 — Relationship representation and predicate declarations

Outcome: every relationship uses the smallest sufficient representation; every asserted relationship has a contract a writer can follow without asking. Produces: direct shaped wref fields or first-class relationship Things where sufficient; PredicateDeclaration/ontology/{predicate} Assertions only for relationships that earn an Arc/Bond Assertion Shape.

Apply the relationship ladder first: can a direct shaped wref answer the competency question completely? If yes, stop. Otherwise ask whether the relationship is a first-class domain object with its own identity or lifecycle. Only then design a claim-bearing Arc/Bond Assertion and its predicate declaration.

For every direct wref, also state whether its meaning is version-bound or identity-bound. The current platform commits wref fields against an exact target version, so version-bound relationships are directly representable. Identity-bound relationships remain a declared platform dependency until the Shape-level binding proposal is accepted and shipped. Do not revise an owning Thing merely to advance a target pin when none of the owner’s own semantic facts changed.

Direct: Measurement.permitRequirement: wref<PermitRequirement> records the singular canonical requirement under which a measurement was reported. The measurement’s provenance path grounds the relationship. Asserted: ownership reported by a particular source, or a contested same-facility resolution, requires attribution, competing claims, and link-specific evidence, so the relationship itself is an Assertion about an Arc or Bond.

Every predicate declares:

PredicateDeclaration/ontology/ownership
  about: Ownership                          # the predicate Shape, version-bound
  subjectPattern: "Organization/identity/**"
  objectPattern:  "Facility/identity/**"
  forwardLabel: "owns"        inverseLabel: "is owned by"
  subjectForm: arc
  subjectNameRecipe: "Arc/identity/rel/{subject-last-segment}--{object-last-segment}"
  structuralCardinality: many:many          # across all history
  concurrentCardinality: many:many          # during overlapping valid time — a different question!
  epistemicClass: normalized-state          # vs source-claim, vs binomial-proposition
  prohibitedSemantics: [operator, permittee, regulatory-authority]
  antiInferences:
    - "permit-issued-to does not imply ownership"
    - "operation does not imply ownership"

Three disciplines: distinguish structural from concurrent cardinality (joint ownership is real; history is longer than any moment). Assign each predicate an epistemic class — a source claim (“source S reports A owns X”), a normalized state (the composition layer asserts it, citing evidence), or a binomial proposition (eligible for certainty opinions later) — and never collapse them into one Shape. And write the anti-inferences down where agents will read them: same address ≠ same facility; permittee ≠ owner; record publisher ≠ issuing authority; no project found ≠ no project exists. Cardinality is semantic, not write-time validation — never force an unresolved relationship into existence to satisfy a schema.

Stage 4 — Naming contracts

Outcome: an agent shown three example names can predict the rest of the namespace; the globs scope queries, subscriptions, and tokens. Produces: NamingContract/ontology/{shape} Assertions, each about its Shape.

NamingContract/ontology/facility
  about: Facility
  nameTemplate: "Facility/identity/epa-frs/{registry-id}"
  exampleNames: ["Facility/identity/epa-frs/110012345678"]
  globs: ["Facility/identity/epa-frs/**", "*/identity/**"]
  identityStabilityTest: "name, address, owner, program-link, or best-pick
                          changes must not change the Registry ID name;
                          follow reviewed FRS correction/split/merge semantics"

Grounding Shapes name by source grain instead — the source’s own stable keys, ordered by how agents scope queries. A per-source repo might use DmrRecord/{state}/{permit}/{feature}/{param}/{period}; a co-located repo might use DmrRecord/grounding/epa/icis-npdes/{state}/{permit}/{feature}/{param}/{period}. The repository’s NamingContract chooses; neither form is universal. The review test before approving any namespace: can an agent infer the convention from examples and predict nearby Things? do globs select useful subtrees? are all segments meaningful, stable, and free of relationships? would an identity-preserving change make any name lie? is it deeper than agents need?

Stage 5 — Golden cases

Outcome: the adversarial pack exists as live data, and the model demonstrably does not lie about any case in it. Produces: GoldenCase/ontology/{slug} Things pointing (wref-typed) at live exemplar Things and Assertions.

Before broad ingestion, hand-model 10–20 adversarial real cases chosen to break the identity tests and cardinality assumptions: facility renamed · rebuilt on the same site · old/new overlapping in time · public owner with private contract operator · permit naming owner rather than operator · two sources reporting locations 500 m apart · a merger forming a regional utility · a source duplicating an entity under two identifiers. The review question for each is one sentence: is the ontology lying about the real-world situation? Golden cases then live forever as regression fixtures, agent eval cases, and onboarding material.

Meridian: several program records linked to one FRS Registry ID test that the adopted authority identity is not forked; a documented FRS correction, merge, or split tests its lifecycle; the contract-operator case tests that Ownership and Operation remain separate predicates; and conflicting source coordinates stay preserved rather than being mistaken for proof that a private facility identity is needed.

Stage 6 — Sources, provenance, temporal model

Outcome: every planned source has a field-level mapping; every future grounded record has a defined path to its logical Source and the exact versioned canonical semantic snapshot that established its claims, at a credential-free durable locator an authorized reader can retrieve. Produces: Source Things (the registry — see the Grounding Shape reference) in each grounding repo; field-level source mappings versioned with the producer implementation (they are implementation contracts, not graph knowledge).

For each source: authority, role, entry points, record classes, observed publication behavior (cadence, corrections — as observed on a stated date). “Definitive” means preferred authoritative source for that claim class, not infallible. The mapping is field-level: every source field is either ignored, preserved on a source Thing, a code-list identity, a provenance field, identity evidence, or a transformation input — and the mapping is versioned; ingestion code implements it rather than embodying it.

The provenance bar: when anyone asks “why do we believe this?”, the answer is never “the EPA.” It is the full graph, every edge a wref:

BELIEF → ASSERTION → NORMALIZED FACT → GROUNDED RECORD
                                             │
                                             └→ SOURCE ARTIFACT STREAM @ exact version
                                                    ├→ SOURCE
                                                    └→ durable canonical semantic bytes

One SourceArtifact Thing is the durable identity of one logical dataset stream from one logical Source; its versions are the stream’s accepted canonical semantic snapshots. The artifact Thing name therefore identifies the stream, not a date, acquisition run, raw file, or hash. Each version carries the SHA-256 and durable locator of its canonical semantic bytes, the accepted/source times, and the stable canonicalization policy. A distinct current semantic hash revises the artifact Thing. Re-observing the current semantic hash is a complete no-op.

For record-oriented sources, use canonical JSONL unless the source contract justifies another canonical form. A correct canonicalization policy:

• projects the complete source claims at the declared stream grain while excluding pagination, response envelopes, request ids, and other transport metadata;
• rejects duplicate or unusable source-grain keys rather than choosing an unstable order;
• sorts records by a source-specific stable key;
• serializes every record with an RFC 8785/JCS-compatible canonical JSON representation, UTF-8, LF separators, and a final LF; and
• proves with adversarial permutation tests that page boundaries and order, object-key order, whitespace, equivalent packaging, and transport metadata do not change the hash, while any changed source claim does.

Do not normalize away source semantics merely to stabilize a hash. For a source whose meaningful artifact is not record-oriented, declare a semantics-preserving canonical form; exact publisher bytes may themselves be that canonical artifact when no justified normalization exists. The invariant is exact canonical source claims, not universal conversion to JSONL.

Raw publisher transport that differs from the canonical semantic artifact is operational replay/debug material, not WarmHub knowledge identity. An adopting producer must place it under an enforced 30-day storage lifecycle. It must not appear in WarmHub fields, durable locators, or logs. Explicitly reviewed, public or sanitized test fixtures may remain in source control when necessary to prove transport parsing; they are fixtures, not production artifact identity. Requests, attempts, retries, response telemetry, deployments, and execution history likewise remain in the producing system’s audit records.

A grounded source-record version pins the exact SourceArtifact version that established its current claims. When a newer artifact repeats a record’s claims, neither that record nor its evidence pin changes. Only source-grain semantic change revises the record and advances its evidence pin. This keeps both the record history and the artifact-stream history meaningful.

Preserve source claims separately from normalized claims — never overwrite a source-reported name with a canonical one. Give every Shape explicit domain-time fields named for what they mean (monitoringPeriodEnd, effectiveFrom, sourcePublishedAt, sourceEffectiveDate); upstream source history is domain data, never a substitute for platform version history or the artifact’s acceptedAt, which records when that semantic snapshot became the stream’s accepted current version.

Stage 7 — Physical design: reconcile, then build

Outcome: repos and Shapes exist, each traceable to contracts and questions, with reconciliation decisions recorded. Produces: the repos and Shapes themselves; OntologyDecision/ontology/od-{id} Things only for choices that meet the decision threshold above.

Only now touch WarmHub. Two rules dominate:

Reconcile before creating; reuse before rebuilding. Apply the Stage-1 existing-semantics gate before physical design, then inventory what already exists and choose the smallest action: reuse · targeted extension · document-and-correct · only then create. repo describe covers part of that inventory — shapes and their field types, per-shape counts, a page of HEAD records, subscriptions, and the repo’s license and write contract. It does not report provenance, producer ownership, or writer bindings; for those, read the repo’s charter and its */ontology/** contracts, and the writer contracts recorded alongside them (Stage 8). The same rule extends beyond your org: when external providers plausibly own a concept, evaluate them (semantic fit, authority, rights, identity stability, stewardship, contract quality, and user workflows) and choose consume · mint-and-bridge · mint. Record that choice as an OntologyDecision only when it meets the threshold above. Never build a parallel greenfield because it is cleaner; require a measurable competency-question benefit that outweighs the interoperability and maintenance costs, and never rename existing Things before evaluating what references them.

Layers stay separate; repos follow owner/visibility/cadence (see the four-layer architecture). Then the Shape mechanics: generate field definitions from the semantic contracts; put the definitions in Shape and field descriptions (agents read them); keep canonical identity Things thin — everything contestable is an Assertion; prefer optional fields (required fields force back-fill decisions); decide the grounding suite’s home (see deployment topologies): component-installed per grounding repo when repos ground themselves, or centrally in a shared grounding repo when one authorized service captures artifacts on several repos’ behalf — grounded records then reference the shared artifacts cross-repo, and domain repos install only the ontology component.

Stage 8 — Writer contracts and the subscription graph

Outcome: every writer has a contract; every composer can rebuild from upstream state. Produces: per-agent contracts (recorded with the repo charter) and the subscription map.

One contract per writer — subscribes-to, reads, writes-only-here, may-create, may-not-create, required behavior (idempotency, provenance, quarantine-the-unresolved) — enforced with name-scoped tokens. Derive output names deterministically from source identity + transformation semantics so replays and duplicate deliveries are no-ops.

Stage 9 — The vertical slice, evaluated against the questions

Outcome: one real question answers end to end with a traversable pedigree; the acceptance criteria pass on live data. Produces: a usable release Set and CompetencyEvaluation Assertions.

Do not implement all domains. Pick one business question and build the narrowest complete path through all four layers. Meridian: one state, one parameter family (ammonia), one flow — grounded permit/limit/measurement records → resolved facilities → normalized measurements beside applicable limits → a PerformancePattern assertion (window, method, version, evidence) → a public RegulatoryPressureAssessment → Meridian’s private FitsICP and WarrantsOutreach. The demo output is not a chatbot answer; it is a traversable pedigree (see the worked example). The graph is the product.

Acceptance, from the earlier stages: identity (the adopted authority or resolution contract survives identity-preserving change; program links do not fork established identities; owner ≠ operator; conflicting locations coexist; unresolved stays unresolved; any departure from established semantics proves its promised CQ benefit) · provenance (every normalized Thing reaches a pinned canonical semantic artifact version and hash) · composition (cross-repo references are wrefs, not copies; source corrections propagate) · query (the question backlog executes) · naming (the review test passes on live data) · trust (“why do we believe this?” and “what, if retracted, would change it?” answer by traversal) · legibility (an unfamiliar reader can tell what a Thing or Assertion means, whom it concerns, why it exists, and how to reach its evidence — without knowing any source schema or private convention).

Then validate with real users: is the representation lying? — and — can you ask the question you actually care about without knowing the source system’s schema?

Record the release at the fixed well-known name Set/ontology/release, with the current contract assertions as members (each about-bound to the Shape version it governs), then evaluate it. A CompetencyEvaluation about each exercised question carries the release pinned to the version under test, the executed query, result digest, and pass/fail. Evaluation is necessarily ex-post (the release must exist to be referenced; nothing stages), so the discipline is release → evaluate → fix in the next release; consumers gate on the evaluation record when they pin dependsOn.

There are two distinct lifecycle cases:

• Fresh repository: install required components, establish today’s reviewed charter, questions, Shapes, contracts, decisions, and golden cases, and create the first usable Set/ontology/release@v1. Do not replay superseded designs or mint placeholder revisions to reproduce version numbers from another repo.
• Existing repository: inventory its actual current ontology and reconcile forward. Revise its existing release Set once the desired contracts are ready; the result is the next real repository-local version, whatever that number is.

For example, a new repository initialized from a reviewed current-state bundle creates usable release v1 directly. A repository already at release v4 revises its contracts and Set to v5; it does not reset to or skip through a prescribed global version. “Release 5 answers question 12” is queryable, auditable, and contestable inside that repository.

Stage 10 — Evolution

Outcome: change has a process: propositions are promoted from practice, revisions are ontology events, open questions are recorded decisions.

• Promote propositions from practice. When the same conclusion keeps appearing in rich-assertion prose, promote it to a precisely defined binomial Assertion Shape with a full proposition contract: positive statement, negation semantics (“no” = observed absent, or merely not found in searched sources as of T?), and temporal qualification — period-qualified propositions put the period in the proposition; never mutate a timeless assertion to mean new periods.
• Layer certainty only where warranted. Veritas opinions attach only to binomial propositions where independent parties can genuinely disagree; opinions live in separate Assertions from the data; the ontology must work with Veritas absent. Rich Assertions explain; binomial Assertions decide; Certainties qualify.
• Shape revisions are ontology events — they may require targeted recomposition, and the affected contracts revise in the same change. Before changing a published contract, name the downstream dependents and their migration. Retract-and-re-add creates fresh identity; revise preserves history and is the default.
• Record only consequential decisions. OntologyDecision Things hold deliberately open or resolved choices that meet the decision threshold: meaningful alternatives, durable rationale, plausible revisitation, and named settling or reopening evidence. Binding semantics still live in the charter or contracts; the decision preserves why another path was rejected.
• Promote reusable method principles with review. Project-specific decisions stay in the adopting repository. At semantic closure, identify any cross-domain candidate and file it with its statement, scope, non-applicability, rationale, supporting examples, counterexample or reopening evidence, and guide/skill/component/migration impact. Unaccepted candidates remain issues. An accepted principle is written once in this guide and applied procedurally by the canonical skill in the same change.
• Re-run the question backlog against each release; the evaluation record is the ontology’s public track record.

The first accepted cross-domain principles are the rules already exercised by the stages above. Their limits matter as much as their slogans:

Principle	Apply when	Do not over-apply when
Start from the knowledge-product boundary and CQs.	Choosing scope and semantics.	Source availability may still phase implementation work.
Reuse established domain semantics unless divergence earns its cost.	A mature authority supplies definitions, identifiers, curation, correction, and familiar workflows that answer the CQs.	An ordinary source key is not canonical merely because it exists; depart when adversarial evidence shows a measurable CQ failure and the benefit exceeds interoperability and stewardship costs.
A Shape or field must pass the CQ deletion test.	Deciding what ships now.	Experimental undeclared fields may remain outside the stable contract.
Grounded records preserve source-native facts.	Layer-1 source capture.	A source-native record may still carry faithful source relationships.
Prefer direct wref → first-class Thing → Arc/Bond Assertion.	Choosing relationship representation.	Attribution or contestability can require the third rung.
Canonical fields earn their lifecycle burden.	Identity resolution and disambiguation where changes version the canonical Thing.	Contestable or merely descriptive source facts stay grounded separately.
Human-readable names are mutable navigation; identity carries continuity.	Designing stable wrefs and useful namespace scopes.	Mechanical segments still belong when they buy query, token, or subscription value.
Domain inactivity is not WarmHub retraction.	A real-world entity closes or becomes inactive.	Retract when the knowledge record itself is withdrawn or replaced by fresh identity.
Preserve representable source disagreement.	Sources make valid conflicting claims.	Quarantine malformed input that violates the source contract.
Canonicalize source semantics, not transport accidents.	A logical dataset stream can arrive through changing pages, envelopes, order, or packaging.	Exact publisher bytes may be the canonical artifact when no semantics-preserving normalization is justified.
New evidence does not revise unchanged knowledge.	A later artifact repeats a grounded record’s current claims.	Revise when source-grain semantics change, even if the producer believes the correction is minor.
Calculate first; materialize only when reuse earns it.	Derived answers can remain query-time work.	Repeated use, subscriptions, latency, or token cost may justify durable knowledge.
Authority-published findings differ from calculations over authority data.	Classifying claims and provenance.	Do not attribute an agent’s calculation to the source dataset’s publisher.
Let real source evidence revise the model.	Profiling contradicts an early Shape or cardinality assumption.	Accepted platform invariants and deliberate source contracts still constrain the answer.
Implementation choices are not ontology decisions or ADRs.	The choice affects execution rather than durable meaning.	Promote it only when an approved CQ makes it durable domain knowledge.