Who Owns Each Model Fact in Ethen

Ethen model metadata looks like one catalog, but every fact has a named owner. Here is how to tell who answers what.

When you read a model page, everything looks like one record: a name, a provider, a context window, a price, a benchmark score, an availability badge. In Ethen, those facts do not come from one place. They come from different systems with different update rhythms and different responsibilities.

Ethen makes that split explicit in a machine-readable authority boundary for MI-R1 consumers, versioned as mi-authority-r1. The contract lists sixteen named facts and assigns each one to exactly one of four owners: model-intelligence, gateway-runtime, cortex-policy, or model-library-projection. A helper, ownerForModelFact, returns the owner for any listed fact. That is the whole idea: if two systems disagree, the contract says which one is supposed to answer.

This article explains that division. It does not claim every consumer already follows the contract perfectly. It describes the intended ownership, what each owner controls, and how provenance decides when a value is displayable at all.

Why one catalog needs four owners

A single owner for all model facts would be simpler to describe and harder to keep correct. Catalog identity changes slowly. Runtime health changes by the minute. A routing choice depends on policy at request time. Display formatting depends on the page, not the model.

Ethen model metadata therefore separates three questions that are easy to confuse:

• What is this model, according to sourced catalog records?
• Can you use it right now, through a specific provider path?
• Which option should a request use, given current policy?

The first question belongs to Model Intelligence. The second belongs to the gateway runtime. The third belongs to routing policy. A fourth owner handles how the answer is formatted for display, without changing the underlying fact.

Freshness and evidence differ by fact type. A context limit can be sourced to documentation with a date and methodology. Availability needs live runtime evidence. A routing decision is a policy outcome, not a model property. Mixing those categories makes stale data look live and policy look like truth.

What model-intelligence owns

Model Intelligence owns eleven of the sixteen facts in the contract:

• identity
• providerMapping
• aliases
• familyVersionLineage
• releaseDeprecation
• capabilities
• contextMaxOutput
• pricingMetadata
• benchmarkMetadata
• provenanceFreshness
• providerPolicy

In practical terms, this is the catalog and evidence layer. It answers: which model is this, who provides it, what it is called elsewhere, where it sits in a family and version line, whether it is released or deprecated, what it can do, how much context it accepts and emits, what its listed pricing and benchmark metadata are, how fresh the provenance is, and what provider policy applies as cataloged policy.

Several of these deserve emphasis because readers often misread them as runtime promises.

pricingMetadata is metadata, not a bill. The contract assigns it to Model Intelligence, which means the catalog is responsible for the listed pricing record and its sourcing. It does not mean the catalog controls what a request will actually cost at execution time under a particular provider, key, or account configuration. If you need the charge for a specific call, that is an execution question, not a catalog question.

benchmarkMetadata is likewise metadata with provenance requirements, not a live claim that a score transfers to your task. The catalog owns the record of the benchmark result and the evidence behind it. Whether two scores are comparable depends on methodology and evidence handling, which is why missing or weakly sourced values are shown as unknown rather than presented as precise comparisons.

providerMapping, aliases, and familyVersionLineage cover naming and grouping so the same model can be recognized across provider labels and version lines without guessing. Keeping them in one owner prevents each consumer from inventing its own equivalence. provenanceFreshness is also owned here: the catalog stores how values were sourced and when, so age or weak support travels with the fact instead of being hidden by the page.

What gateway-runtime owns

The gateway runtime owns three facts:

• runtimeAvailability
• providerCertification
• latencyTtftReliability

This is the live-execution layer. It answers: is this model reachable now, is this provider path certified for this kind of use, and what do we know about latency, time-to-first-token, and reliability from runtime observation?

The key distinction is runtimeAvailability versus catalog existence. A model can be correctly cataloged by Model Intelligence and still be unavailable through a particular runtime path. The catalog says the model exists and has certain properties. Only the runtime can say whether a request can be served now.

providerCertification is about a provider route being approved for execution, not about the model name appearing in a catalog. A new provider mapping does not by itself certify the route. latencyTtftReliability is runtime-observed behavior, not documentation prose. Only runtime telemetry can speak to current serving behavior, so keeping this fact with the gateway runtime prevents catalog text from being mistaken for a service promise.

If you remember one rule from this article, make it this one: catalog presence is not execution proof. Model Intelligence can tell you a model is real and described; the gateway runtime tells you whether it is usable here and now.

What cortex-policy owns

Routing policy owns one fact:

• routingDecision

That single assignment carries a large conceptual point. Routing is a decision, not a description. It is owned by cortex-policy, not by the catalog and not by the runtime alone.

Model Intelligence may supply the inputs: identity, capabilities, constraints, and metadata. The gateway runtime may supply availability and observed behavior. But the choice of which eligible model or provider path should handle a request is a policy outcome. It can depend on eligibility rules, health signals, budgets, and other request-time inputs that no static catalog row can settle in advance.

This is why a routing result should never be read back into the catalog as if the chosen model were objectively best. The contract treats the decision as owned by policy precisely because the same catalog and the same runtime inputs can yield a different decision under different policy. If you want to audit routing, audit the policy and its inputs at decision time, not just the model name that was selected.

What model-library-projection owns

The fourth owner handles one fact:

• displayFormatting

model-library-projection owns how a fact is presented, not whether it is true. This covers the projection from stored evidence into a readable page: labels, ordering, grouping, number formatting, and other presentation choices.

The separation protects both sides. Display code can improve readability without claiming authority over catalog truth or runtime health, and catalog owners are not at fault for a misleading label. When something looks wrong, the first question is whether the owned fact is wrong or the projection of a correct fact misleads. Two pages can also legitimately format the same evidence differently for different audiences.

Canonical providers: explicit aliases only

Provider naming is a quiet source of model-page errors. External inventories use different labels for the same organization, and naive string matching creates false merges or false splits.

Ethen handles this with an explicit alias map, not inference. The source comment is direct: explicit external inventory aliases, never infer provider equivalence. In the inspected contract, the map contains exactly two entries:

• moonshotai resolves to kimi
• zai resolves to z-ai

The function resolveCanonicalProviderId returns the canonical identifier when the input appears in that map, and otherwise returns the input unchanged. There is no fuzzy matching, no substring rule, and no hidden list. If a provider identifier is not in the map, it is its own canonical form until an explicit entry says otherwise.

This conservative behavior is a feature. It prevents the catalog from asserting that two similarly named providers are the same organization without evidence. The tradeoff is that unmapped variants stay unmerged. Readers should therefore treat provider grouping as exactly as complete as the explicit map, not as a universal entity-resolution system.

Known or Unknown: how provenance gates display

Ownership says who answers. Provenance says whether there is enough evidence to show an answer at all.

Every evidence-backed value in this design carries an MIProvenance record with fields for sourceUrl, sourceLabel, retrievedAt, methodology, and confidence, plus optional fields for source type, effective and expiry dates, source hash, and methodology version. Confidence is one of high, medium, low, or unknown. The display wrapper, MIEvidenceState, is either known with a value or unknown with an explanation.

The gating function, createEvidenceState, is strict. A value counts as complete only when all of these hold:

• the value itself is not null,
• sourceUrl is present,
• retrievedAt is present and parses as a valid date,
• methodology is present,
• confidence is neither low nor unknown.

If any requirement fails, the result is unknown: the stored value becomes null, the display value becomes the string Unknown, and the reason defaults to a sentence requiring a sourced value, retrieval date, and methodology. Only a fully supported input returns known with its value and display value intact.

This is why Ethen model pages can show Unknown where another catalog might show a confident-looking number. An Unknown is not necessarily a missing measurement; the value may exist but lack a retrievable source, valid date, stated methodology, or sufficient confidence. Each gap is actionable: add the source link, record retrieval time, document the method, and reassess confidence.

Reading chart provenance without overtrusting it

A second helper, chartProvenance, builds provenance for charted benchmark data from a smaller set of inputs: a canonical URL, a retrieval timestamp, a source type, and a methodology or description. Its behavior shows how carefully confidence is assigned.

The source label depends on source type. When the source type is json_ld_dataset, the label is Published benchmark dataset. Otherwise the label is Committed normalized dataset. The retrieval date is kept only when it parses as a valid date; otherwise it becomes null. Methodology falls back from an explicit methodology field to a description field, and then to null when neither exists.

Confidence follows the same narrow rule: json_ld_dataset receives medium, anything else receives unknown. There is no path here to high. Chart provenance alone never establishes strong confidence, and a non-dataset source fails the createEvidenceState gate, which rejects both low and unknown. Before comparing charted scores, inspect the label and fields. Neither label proves two points shared the same task definition, harness, or scoring rules; comparability needs methodology equality, not just a shared chart.

Three examples that show the split

A context window question shows the catalog boundary. Suppose you ask for a model's maximum input and output lengths. That is contextMaxOutput, owned by Model Intelligence. The answer should come with provenance: where the limit was documented, when it was retrieved, how it was determined, and a confidence level that survives the evidence gate. If any of that is missing, the correct display is Unknown, not a guessed number carried over from a similarly named variant.

An availability question shows the runtime boundary. Suppose the same model is listed correctly with full provenance, but your request fails or the model selector greys it out. That is runtimeAvailability, owned by the gateway runtime. The catalog was not necessarily wrong. Availability is a live property of a provider path, and it can change without any change to the model's identity, capabilities, or documentation. Debugging should start with runtime status and certification for that path, not by editing the catalog row.

A selection question shows the policy boundary. Suppose two models both match your capability filter and both appear available, yet the system picks one of them. That pick is a routingDecision, owned by cortex-policy. The explanation lives in the policy inputs at that moment: eligibility, health, budget, and whatever else the configured policy considers. The catalog can tell you what each candidate is. The runtime can tell you what each path looked like. Only the policy record can tell you why this request went left instead of right.

What this contract does not prove

An authority contract is a promise about responsibility, not evidence that every reader already honors it. Version mi-authority-r1 says which owner should answer each of sixteen facts and provides ownerForModelFact so consumers can look that up. It does not by itself prove that all pages, APIs, selectors, and logs already resolve every fact through the correct owner with no stale copies, no local overrides, and no presentation shortcuts.

Several concrete limits follow from the inspected sources.

First, the contract covers the facts it names. Anything outside MODEL_FACT_AUTHORITY has no assigned owner in this file. New fact types need explicit additions before consumers can rely on a lookup.

Second, the provider alias map covers exactly the entries it lists. With two explicit mappings in the inspected revision, most provider identifiers pass through unchanged. Any broader grouping claim would need a larger verified map, not an assumption that similar names were already reconciled.

Third, the provenance gate is only as good as its inputs. createEvidenceState enforces that a displayable value has a source, a date, a methodology, and adequate confidence. It cannot verify that the linked source actually supports the value, that the methodology was applied correctly, or that two methodologies are equivalent. Passing the gate means displayable, not necessarily comparable.

Finally, display remains a separate layer. Because displayFormatting is owned by the projection, a correct underlying fact can still be misread if the page formats, groups, or labels it poorly. When a number surprises you, check the provenance and the owner before assuming the catalog, the runtime, or the policy is at fault.

A short way to use the map

Before you trust a model fact, ask two questions. Who owns it, and what evidence came with it? If the fact is identity, lineage, capability, context, pricing metadata, benchmark metadata, or another catalog record, the owner is Model Intelligence and you should expect sourcing. If the fact is availability, certification, or observed latency behavior, the owner is the gateway runtime and you should expect live evidence. If the fact is which model a request used, the owner is routing policy and you should expect a decision record. If the wording or layout confuses you, suspect the display projection before you suspect the underlying systems.

That habit will not make every page perfect, but it will keep you from asking the catalog a runtime question or asking a routing log a catalog question. In a system with many models and many paths, knowing who owns each fact is the fastest route to a useful answer.