Reference

Shows when CTXDEX last captured or verified a time-sensitive reference fact.

Use **Captured As Of** to judge the freshness of information that can change over time.

It records CTXDEX's knowledge or evidence time: when the information was captured, verified, or treated as the current reference. It does **not** tell you when the underlying fact became effective.

For example, pricing can be captured before a future Rate becomes effective, and an industry comparison can be captured at a later date even though the compared models were released earlier.

Shows when a fact, price, status, or commercial condition starts to apply.

**Effective From** is the start of an effective-time interval.

For pricing and other effective-dated records, CTXDEX uses the date to decide when the record becomes applicable. A fact can be captured or announced before this date, so **Effective From** must not be replaced with a captured or publication date.

Shows when an effective-dated fact stops applying.

**Effective Until** is the end boundary of an effective-time interval.

Where CTXDEX uses half-open intervals, a record applies up to—but not including—the end instant. A successor record can therefore begin at exactly the same instant without overlap.

An expired price or status must not be silently carried forward as current.

Shows when a Model or Snapshot was released, not when CTXDEX captured the record.

A **Released** date describes the release of a Model or Snapshot.

It is different from **Captured As Of**, which describes CTXDEX's evidence/freshness time, and from pricing effective dates, which describe when a commercial price applies.

CTXDEX keeps these dates separate so release history, data freshness, and commercial validity are not mixed together.

Shows when CTXDEX last verified an externally maintained reference record.

**Verified At** is an editorial or source-verification timestamp used for externally maintained reference information.

It records when CTXDEX checked the reference against its supporting evidence. It is not a substitute for the item's release date, captured-as-of date, or commercial effective dates.

Shows the date and time the Calculator uses to choose applicable pricing.

**Pricing Effective At** is the timestamp against which CTXDEX resolves effective pricing.

The Calculator selects the Pricing Policy Version, Rate Schedule, Rates, and related effective-dated pricing that apply at this time. Historical estimates use historical pricing; future estimates can use scheduled future pricing where it exists.

This is different from when CTXDEX captured the pricing data.

Unknown means the value should be meaningful but is not known; Not Applicable means the concept does not apply.

CTXDEX keeps **Unknown** and **Not Applicable** separate.

- **Unknown** — the concept is meaningful for the subject, but the value is not currently known, verified, or available. - **Not Applicable** — the concept itself does not meaningfully apply to that subject.

Neither state should be collapsed into a dash or treated as the other. This distinction is important for filters, comparisons, performance metrics, and technical characteristics.

Missing or unpublished pricing must not be interpreted as a free price.

A missing or unknown price is **not** the same as a zero Rate.

CTXDEX treats an explicit `0` Rate as valid pricing data only when the commercial pricing authority actually says the charge is zero. If pricing is unpublished, negotiated, unavailable, or missing, the UI should show that state rather than inventing a free price.

This prevents incomplete pricing from producing misleading cost estimates.

A Model is the continuing identity; a Snapshot is a specific dated or immutable state.

CTXDEX resolves a Snapshot from the Model plus any Snapshot-specific overrides.

```text Model-level facts + Snapshot overrides = resolved Snapshot view ```

A Snapshot therefore does not need to repeat every capability or representation. Missing Snapshot override data must not automatically be interpreted as lack of support.

The Publisher releases the Model; the Provider serves or commercially offers it.

CTXDEX keeps these roles separate because they describe different responsibilities.

- **Publisher** — creates or publishes the Model in its model portfolio or lineage. - **Provider** — makes the Model available through an inference or commercial serving channel.

The same organization can hold both roles, but a Model can also be published by one organization and served by several Providers.

Model facts describe the Model; a Commercial Offering describes how a Provider makes it available.

A **Model** owns intrinsic technical identity and characteristics.

A **Commercial Offering** describes a Provider-specific way that Model or Snapshot is made available. Provider, access path, delivery mode, processing tier, capacity options, commitments, service availability, lifecycle, and pricing can vary by Offering.

CTXDEX therefore does not treat commercial availability or price as intrinsic Model properties.

A Model is the model identity; a Distribution is a particular downloadable or distributable artifact.

A **Model Distribution** records a way model artifacts are made available for download, installation, or distribution.

It is separate from the Model's identity and from managed inference access. A Model can have no downloadable artifact, one artifact, or several distributions with different formats or conditions.

Artifact availability therefore must not be inferred solely from openness labels.

Model openness, legal use terms, and downloadable artifact availability are separate facts.

CTXDEX does not use one “open” label to stand in for several different questions.

- **Openness classification** describes the degree or form in which weights/source are available. - **Licence** records the legal terms governing use and redistribution where known. - **Distribution** records whether and how a downloadable artifact is actually made available.

A model can have open weights without being open source, can be source-available under restrictive terms, or can have a licence record without a downloadable distribution. These facts should be shown independently.

A Model capability is intrinsic support; a Service is a separately available commercial/tool capability.

A **Capability** describes what the Model itself supports.

A **Service** is a separately identifiable tool or commercial capability made available alongside model inference, such as Web Search, File Search, or Code Execution.

A Service may have its own availability and pricing. The existence of a Model capability does not imply that a separately billed Service is available, and a priced Service does not imply every Offering supports or invokes it.

A technical context limit and a commercial long-context pricing threshold are different concepts.

The **Context Window** is a technical Model characteristic describing the amount of context the Model can support.

**Long-Context Pricing** is a commercial condition that can change pricing after a Provider-defined threshold is crossed.

The pricing threshold can be lower than the Model's technical maximum, and a large Context Window does not by itself mean long-context pricing exists.

A pricing Rate is a monetary conversion; a rate limit is an operational usage constraint.

In CTXDEX, **Rate** in the pricing model means an atomic monetary price such as currency per token, image, minute, request, or capacity-time unit.

A **rate limit** is an operational constraint such as requests per minute, tokens per minute, or another provider-enforced usage limit.

They can both affect a user, but they answer different questions and must not share the same semantic meaning.

Historical records remain available for reference but must not be presented as current availability or pricing.

CTXDEX preserves historical Models, Snapshots, Offerings, and prices so users can understand earlier states and reconstruct earlier costs.

**Current** means applicable now under the relevant lifecycle/effective-date rules. **Historical** means retained for past interpretation.

A historical Offering or expired Rate must stay visibly historical. CTXDEX does not carry it forward as current merely because it is the most recent record available.

Latency and throughput usually describe a serving configuration, not an intrinsic Model property.

Ordinary serving performance can change with Provider infrastructure, Serving Surface, region, delivery mode, processing tier, capacity, concurrency, and workload.

CTXDEX therefore normally attaches latency and throughput reference values to the applicable Commercial Offering, Serving Surface, or capacity configuration rather than to the bare Model.

A Model-level performance value is appropriate only when the metric is genuinely standardized and deployment-independent.

TTFT measures the delay until the first generated text token becomes available.

Use TTFT to understand **startup responsiveness** for interactive text generation.

It does not describe how fast the rest of the response is generated. Read it together with Output Tokens per Second and the recorded workload/serving conditions.

TTFT values with different workloads, tiers, regions, or Measurement Bases should not be treated as automatically comparable.

Shows the generated text-token rate after generation has started.

Output Tokens per Second describes the **generation rate after the first token**.

It complements TTFT: one metric describes the startup delay and the other describes ongoing output speed. It is a serving-performance measure, not the number of tokens billed and not a provisioned-capacity unit.

Always interpret it with the stated workload profile and serving conditions.

Defines the fixed test workload behind a latency or throughput value.

Performance numbers are only interpretable when the workload is known.

A **Workload Profile** records the reference input size, output target, modality-specific characteristics, and other assumptions used for the performance value. It allows metrics to be interpreted and compared within the intended scope.

This performance Workload Profile is different from the Calculator's **Workload** category, which is mainly a discovery/defaulting aid.

Shows whether a performance value is synthetic, benchmark-measured, provider-published, or contractual.

The **Measurement Basis** describes how a performance value was obtained or asserted.

CTXDEX can distinguish synthetic reference profiles, benchmark measurements, Provider-published values, and contractual SLA values. This is separate from the statistic itself: for example, P95 describes how the measurements are summarized, while the Measurement Basis describes the evidence source.

Synthetic Profile values are CTXDEX reference/demo data and are not measured external-provider telemetry.

Shows a Provider-specific way the Model or Snapshot is commercially available.

A Model can have more than one **Commercial Offering**.

Offerings can differ by Provider, access path, Serving Surface, delivery modes, processing tiers, capacity options, commitments, Services, lifecycle, and pricing. These are commercial/serving facts and do not change the intrinsic identity of the Model.

Pricing and calculator flows therefore resolve through the selected Offering rather than through a bare Model.

Describes how a request or job is executed and how results are delivered.

Allowed Delivery Modes come from the authoritative commercial/serving data for the selected Offering and Serving Surface.

Examples can include synchronous, streaming, asynchronous, batch, and realtime delivery, but the UI should display only values actually supported by the selected configuration.

Delivery Mode remains separate from **Processing Tier**, which describes scheduling or service treatment.

Describes the Provider-defined scheduling or service treatment used for a supported serving path.

Processing Tier is a separate commercial/serving dimension from Delivery Mode.

A tier can affect latency treatment, commercial conditions, and pricing, but only tiers supported by the selected Offering/Serving Surface should be selectable. Changing Delivery Mode can also constrain which Processing Tiers remain valid.

CTXDEX must not infer unsupported combinations simply because both values exist elsewhere in the catalogue.

No current Offering is different from historical-only availability and from having no Offering recorded at all.

CTXDEX keeps commercial availability states distinct:

- **Current Offering available** — at least one applicable current Offering exists. - **Historical or deprecated only** — Offering history exists, but there is no current Offering. - **No recorded Offering** — CTXDEX has no Offering record for the subject.

These states are not Model lifecycle statuses and should not all be rendered as the same empty value.

The billing meter identifies what quantity the Provider actually charges.

A pricing amount is meaningful only together with the quantity it prices.

CTXDEX keeps **metering** separate from the monetary Rate. Raw scenario usage is first converted by the applicable Metering Profile into a **Billable Quantity**. The Rate then values that quantity using the Provider's Billing Unit and denominator.

This is why two Providers can price similar workloads differently—for example by tokens, images, seconds, pages, requests, or a derived storage/capacity unit.

CTXDEX preserves the unit and denominator the Provider actually publishes instead of converting everything to tokens.

Provider-native units are part of the commercial meaning of a price.

CTXDEX therefore keeps Rates in units such as tokens, images, seconds, minutes, pages, robot-hours, or throughput-unit-hours when those are the published billing units. It also preserves denominators such as “per 1 million tokens” instead of rewriting every Rate into a tiny per-unit value.

Derived normalized economics can be calculated for analysis, but they are not substituted for the canonical Provider Rate.

Cached input is normally a subset of input that can receive different commercial treatment when the Provider supports prompt caching.

CTXDEX separates ordinary input from **Cached Input** so the same tokens are not charged twice.

When cached usage is a subset of total input:

```text uncached input = total input - cached input ```

The cached portion is then priced exactly once using the Provider's published representation—either an explicit cached-input Rate or a cache-read discount/multiplier, not both for the same economic event.

Cache write and cache storage are separate possible charges and should not be assumed to equal cached-read usage.

Batch is a Delivery Mode and can have a different rate card from ordinary request processing.

**Batch** describes job-oriented delivery/execution. It is not the same concept as an **Economy Processing Tier**.

Where the selected Commercial Offering supports Batch and the Provider publishes separate Batch economics, CTXDEX can select the applicable Batch pricing branch or pricing treatment.

If Batch is not supported by Set-1 commercial availability, pricing data must not make it appear available.

Priority is a Processing Tier that can receive different commercial treatment from Standard processing.

A **Priority Processing Tier** can change scheduling/service treatment and, where the Provider publishes it, can also change pricing.

Priority is separate from Delivery Mode. A request can have a delivery mode such as synchronous or streaming and independently use a supported processing tier.

CTXDEX exposes only tier choices supported by the selected Commercial Offering and applies the pricing representation recorded for that tier.

An allowance covers eligible usage up to a defined amount before paid overage begins.

An **Allowance** is not a permanent zero Rate.

It normally operates over a defined scope and period—for example, the first number of eligible queries per organization per month. **Included Usage** is the portion covered by that allowance. Once the allowance is exhausted, remaining eligible usage can be priced at the applicable overage Rate.

The scope, reset period, and covered usage must therefore be considered when estimating cost.

Commitment pricing depends on the exact commercial commitment option, not only a generic committed/not-committed flag.

CTXDEX represents specific **Offering Commitment Options** because commitments can differ in term, covered capacity, effective period, and commercial treatment.

A one-month and a twelve-month commitment may share the same broad type but have different prices. Capacity and commitment can also coexist.

Commitment Pricing remains separate from a customer-specific **Commercial Agreement**, which can contain negotiated terms beyond public commitment options.

A spend commitment is a period-level minimum-spend obligation, not a per-request minimum charge.

A **Spend Commitment** is evaluated over its defined commercial period and eligible scope.

For example, if an agreement requires a minimum eligible spend for a month, CTXDEX should compare accumulated eligible charges with that obligation and represent any shortfall as a period-level true-up.

It must not apply the monthly commitment as a floor to each individual request or single workload estimate.

Provisioned or dedicated capacity is priced in the Provider's native capacity units rather than being forced into token Rates.

Capacity offerings can fundamentally change the billing model.

Provisioned Throughput or Dedicated Compute can be sold using provider-defined capacity units multiplied by time. CTXDEX keeps that **canonical capacity bill** in its native unit.

The Calculator can separately derive workload economics—such as an effective cost per million tokens—when a utilization scenario is supplied. That analytical result is not the Provider's canonical Rate and should not replace it.

Tools and ancillary Services can add charge components separate from Model inference.

Services such as Web Search, File Search, Code Execution, Grounding, or other add-ons can have their own pricing authority and billing meter.

CTXDEX keeps these charges separate from Model inference so the estimate can show which component produced each cost.

A published Service price does not by itself mean the Service is supported by the selected Offering, invoked in the scenario, or separately billed. **Available**, **invoked**, and **billed** remain separate states.

These are dated, broad real-world reference comparables—not claims that the models are equivalent.

CTXDEX uses Similar Industry Models to give users recognizable external reference points for a synthetic ctxdex Model.

The comparison is **directional and dimension-specific**. A listed model can be broadly comparable for reasoning, coding, multimodal capability, image generation, robotics, document intelligence, or another recorded Comparison Basis while differing in many other ways.

V1 does not assign a numerical similarity score, and “similar” must not be read as equivalent or interchangeable.

Shows the dimensions used to explain why an industry model is considered comparable.

A **Comparison Basis** scopes the comparison.

The recorded dimensions can describe areas such as reasoning, coding, multimodal capability, image generation, audio, video, scientific use, robotics, document intelligence, or retrieval. More than one basis can apply.

Always interpret the comparison through these dimensions and the accompanying rationale rather than as a whole-model equivalence statement.

Shows when CTXDEX captured or verified the current industry-comparison set.

Industry models, product positioning, and capabilities change over time, so CTXDEX comparison sets are visibly dated.

The **As Of** date is the comparison set's captured-as-of/evidence date. It tells you when CTXDEX last treated those external references as the applicable comparison set; it is not the release date of every compared model.

Use the date when interpreting or revisiting a comparison.

Workload helps you enter the Calculator with useful defaults; it does not decide the price.

The Calculator's **Workload** choice is primarily a discovery and defaulting aid.

It can choose a sensible starting Model, Commercial Offering, and starter scenario. A Model can appear under more than one Workload entry point.

The actual form fields and cost are then derived from the selected commercial/pricing configuration. Workload is therefore not a pricing rule and is different from a Model Task or a performance Workload Profile.

The Calculator asks only for usage quantities required by the selected Offering and its pricing/metering structure.

Usage fields are dynamic because not every Model or Offering is billed the same way.

A text scenario may need input and output tokens; an image scenario may use image count and quality; audio can use duration; documents can use pages; robotics or capacity can use provider-native time/capacity units. Multimodal scenarios can contain several Usage Components at once.

Model modality or capability does **not** by itself determine which fields are billable.

The result status tells you whether CTXDEX could produce a complete, unambiguous estimate.

Calculator results distinguish at least:

- **Complete** — all required components were priced successfully. - **Incomplete** — required usage or pricing components are missing. - **Ambiguous** — more than one unresolved pricing branch/rate applies. - **Unavailable** — no applicable published/reference pricing exists for the requested configuration/time. - **Invalid** — the submitted scenario violates validation or availability rules.

CTXDEX must not present incomplete, ambiguous, unavailable, or invalid results as an ordinary complete total.

CTXDEX keeps the canonical capacity charge separate from derived cost-per-workload analytics.

For provisioned or dedicated configurations, the Provider may bill capacity in units such as throughput-unit-hours or dedicated deployment time.

That **canonical capacity bill** remains authoritative. If you also supply workload/utilization assumptions, CTXDEX can derive analytical economics such as effective cost per million tokens or per request.

These derived workload economics are scenario-dependent comparison metrics; they are not rewritten Provider Rates and should be labelled accordingly.

The Calculator result is an estimate derived from CTXDEX pricing data and your scenario; it is not a Provider invoice.

CTXDEX calculates an **estimate** from the selected commercial configuration, pricing-effective time, scenario usage, applicable meters, Rates, Services, and other pricing conditions.

The result is intended for planning and explanation. It is not observed Provider telemetry, a reconciled invoice, or a settled billing record.

The charge breakdown and Calculation Explanation show how the estimate was derived and which material assumptions affected it.

CTXDEX is a structured model, commercial, pricing, comparison, and cost-estimation reference.

CTXDEX brings model information, commercial availability, pricing, industry references, and cost estimation into one structured catalogue.

The product deliberately separates **what a Model is** from **how it is made available and priced**. Technical model characteristics belong to the Model or its Snapshot; provider-specific access, serving, capacity, and commercial conditions belong to Commercial Offerings and related serving objects; pricing is resolved through the applicable commercial pricing authority.

CTXDEX is also designed as a knowledge resource. Glossary definitions explain what concepts mean, while methodology and help content explain how CTXDEX represents and uses those concepts.

CTXDEX organizes Model, commercial, pricing, performance, comparison, and calculator information as separate but connected layers.

CTXDEX organizes information into several connected layers:

- **Model information** — identity, family, modalities, representations, capabilities, tasks, technical characteristics, openness, licence, lineage, and related model facts. - **Commercial and serving information** — publishers, inference providers, Commercial Offerings, Serving Surfaces, delivery modes, processing tiers, capacity options, commitments, services, and availability history. - **Pricing information** — published rate-card structures, meters, Rates, allowances, commitments, capacity charges, service charges, and effective-dated pricing. - **Performance information** — serving-performance reference metrics such as latency or throughput, always interpreted with their workload and serving conditions. - **Industry-reference information** — dated Similar Industry Model comparisons with explicit comparison dimensions and source references. - **Calculator information** — configured workload quantities, assumptions, estimated charge components, and calculation explanations.

Current counts, coverage, and freshness dates are derived from catalogue/read-model data rather than embedded in this editorial text.

CTXDEX keeps intrinsic Model facts separate from Snapshot overrides, Commercial Offering facts, and serving-dependent information.

CTXDEX uses semantic ownership rules so that information is stored and interpreted at the level where it actually belongs.

**Model-level information** describes the model itself: identity, family, modalities, tasks, capabilities, technical characteristics, openness, licence, and similar intrinsic facts.

**Snapshot information** records a dated or immutable model state. A resolved Snapshot view combines Model-level facts with Snapshot-specific overrides; absence of a Snapshot override does not by itself mean the Snapshot lacks that capability or characteristic.

**Commercial Offering information** describes how a Model or Snapshot is made commercially available by a Provider. Provider, access path, delivery mode, processing tier, capacity, commitment, service availability, and related commercial facts are therefore not treated as intrinsic Model properties.

**Serving performance** is normally deployment-dependent. Latency and throughput can vary with provider infrastructure, Serving Surface, processing tier, capacity, region, workload, and concurrency, so ordinary serving-performance values belong to the applicable serving/commercial context.

CTXDEX also preserves applicability states carefully. **Unknown** means a meaningful value is not currently known or verified; it does not mean unsupported or Not Applicable.

A Model is the continuing model identity; a Snapshot is a dated or immutable state of that Model.

A **Model** is the canonical identity that continues across its recorded lifecycle. A **Model Snapshot** is a specific dated or immutable state linked to that Model.

CTXDEX resolves a Snapshot by combining the Model-level state with Snapshot-specific overrides:

```text Model-level facts + Snapshot-specific overrides = resolved Snapshot view ```

This matters because a Snapshot does not need to repeat every Model fact. If a Snapshot does not override a Model-level capability or representation, that absence must not automatically be interpreted as lack of support.

Snapshot release dates, identifiers, lifecycle facts, and genuine Snapshot-specific changes remain available where recorded.

The Publisher releases the Model; the Provider makes it available through a serving or commercial channel.

CTXDEX keeps **Publisher** and **Provider** as separate roles.

A **Publisher** is the organization responsible for releasing or publishing a Model as part of its model portfolio or technical lineage.

A **Provider** is the organization that makes the Model available through an inference or commercial serving channel.

The same organization can perform both roles, but the distinction remains important. A Model can be published by one organization and served by multiple Providers, and those Providers can offer different access paths, capacity options, performance characteristics, and prices.

CTXDEX represents pricing as commercial, effective-dated data rather than assigning one price directly to a Model.

CTXDEX does **not** assign one naked price to a Model. Price is commercial: the same Model can be offered by different Providers, through different commercial paths, under different pricing conditions.

For model inference, pricing normally starts from the selected **Commercial Offering** and resolves the applicable effective pricing authority, rate-card branch, meters, Rates, and commercial rules. Separately priced Services, routes, or customer agreements can contribute their own charge components when they are applicable.

CTXDEX preserves **provider-native billing units and denominators**. Text may be priced by input and output tokens, while other offerings can use images, seconds, minutes, pages, requests, robot-hours, throughput-unit-hours, or other provider-defined units. CTXDEX does not invent token conversions merely to make unlike prices look uniform.

Metering and monetary valuation remain separate: a Metering Profile derives the billable quantity, and a Rate values that quantity. Historical and scheduled pricing are preserved through effective dating rather than overwriting prior commercial truth.

The Pricing experience shows reference rate structures; the Calculator applies those structures to a configured workload.

The **Pricing** experience and the **Pricing Calculator** serve different purposes.

```text Pricing reference → shows published/reference rate-card structures and commercial pricing context

Pricing Calculator → applies canonical pricing to a configured workload and returns an estimate ```

The Calculator accepts scenario quantities and relevant commercial choices, resolves the authoritative pricing server-side, meters the scenario into billable quantities, and calculates separate charge components before producing a total.

The Calculator does not become a second pricing authority. It must re-resolve canonical pricing rather than trusting rates passed through UI navigation or hard-coded frontend logic. Its result is an **estimate**, not a provider invoice or settled billing record.

A Commercial Offering represents a Provider-specific way a Model or Snapshot is made available.

A **Commercial Offering** is the provider-specific commercial availability object around a Model or Model Snapshot.

Different Offerings of the same Model can vary in Provider, access path, availability period, Serving Surfaces, delivery modes, processing tiers, capacity options, commitments, services, and pricing. These differences do not change the intrinsic identity of the underlying Model.

A **Serving Surface** is a concrete serving interface or path within an Offering. It can carry delivery-mode, tier, capacity, or performance context, but it is not automatically a separate priced subject unless the surface itself is independently sold or priced.

CTXDEX therefore resolves availability and pricing through the applicable Commercial Offering rather than inferring commercial truth directly from a bare Model.

Industry comparisons are dated, dimension-specific reference comparisons and are not claims of equivalence.

CTXDEX can show **Similar Industry Models** to give users recognizable real-world reference points for synthetic ctxdex models.

These comparisons are **directional and dimension-specific**. A comparable can be selected because of reasoning, coding, multimodal capability, image generation, realtime interaction, scientific use, robotics, document intelligence, retrieval, or other controlled comparison dimensions. The recorded Comparison Basis and similarity summary explain what part of the model positioning is being compared.

A listed model is therefore **similar or broadly comparable**, not equivalent or interchangeable. CTXDEX does not assign a numerical similarity score in V1.

Industry references are externally maintained and time-sensitive. Each comparison set carries a visible captured-as-of date, supporting rationale, methodology version where applicable, and source references so users can interpret the comparison in its proper market context.

CTXDEX separates when information was captured from when the underlying fact is effective.

CTXDEX uses different dates for different kinds of truth and does not collapse them into one ambiguous “last updated” value.

- **Captured As Of** tells you when CTXDEX captured, verified, or treated a time-sensitive reference fact as its known reference. - **Effective From** and **Effective Until** describe the interval during which a commercial, pricing, lifecycle, or other effective-dated fact applies. - **Released** describes when a Model or Snapshot became available or was released. - **Verified At**, where present, records an editorial or source-verification timestamp for externally maintained reference data.

A fact can be captured before it becomes effective, or captured recently while describing an older effective period. For that reason, database `updated_at` timestamps are not used as substitutes for user-facing captured/effective dates.

Current dates shown by the UI are derived dynamically from the relevant catalogue or read-model authority.

CTXDEX preserves historical Models, Offerings, Snapshots, and pricing so past states can be interpreted without presenting them as current.

CTXDEX preserves historical records where they are useful for understanding model and commercial evolution.

Historical Models, Snapshots, Commercial Offerings, replacements, and pricing can remain available for reference even after they are no longer current. Effective-dated pricing is retained so an estimate for an earlier period can resolve the price that applied at that time instead of reusing the current rate.

Historical information must remain visibly historical. A deprecated or historical Offering must not be presented as current availability, and an expired Rate must not be silently carried forward as current pricing.

Likewise, a newer item is not automatically treated as the replacement for an older one unless an explicit lineage or replacement relationship is recorded.

CTXDEX V1 uses a constructed synthetic model and pricing universe to exercise the catalogue and calculator architecture.

The CTXDEX V1 catalogue uses **synthetic ctxdex Models, Commercial Offerings, and pricing data** constructed to exercise the model-information, commercial, pricing, comparison, and calculator systems.

Synthetic ctxdex Models and prices must **not** be interpreted as actual external vendor products, published external rate cards, or claims about real-world provider commercial terms.

CTXDEX also contains separately maintained **real-world industry reference data**, such as Similar Industry Models. Those records are externally researched, source-referenced, and visibly dated; they are not part of the synthetic model universe.

Where serving-performance data is marked with a **Synthetic Profile** Measurement Basis, it is reference/demo performance for the stated workload and serving conditions, not measured external-provider telemetry or a contractual SLA.

CTXDEX is a structured reference and estimation system; some facts are unavailable, context-dependent, synthetic, or qualitative.

CTXDEX should be interpreted with the following limitations in mind:

- Some technical characteristics can be unavailable, undisclosed, or not applicable. **Unknown** does not mean zero, false, unsupported, or Not Applicable. - Serving performance can vary materially by Provider, Serving Surface, region, processing tier, capacity, concurrency, and workload. Performance values should be read with their workload profile, Measurement Basis, statistic, and captured-as-of context. - Similar Industry Model comparisons are qualitative, dimension-specific references. They are not benchmark equivalence, interchangeability, or a numerical similarity score. - Publicly represented pricing does not necessarily describe negotiated enterprise terms. Customer-specific Commercial Agreements can have different commercial treatment. - Cost Calculator results are estimates derived from the selected scenario and applicable pricing; they are not provider invoices or observed settled charges. - Historical and externally changing information should be interpreted using the visible effective and captured-as-of dates. - Synthetic CTXDEX models, pricing, and synthetic-profile performance values are constructed reference data and must not be presented as external vendor facts.