CTR-EDW · version 2
Enterprise Data Warehouse — Conformed fact rows
The honest caveat on this contract: a conformed row is already an interpretation. Where a figure resolves to the warehouse rather than to the ledger, the lineage surface says so.
What the contract says
These are the terms the connector is generated against. A source that stops matching them is a drift finding, not a silent data change.
Review state
Neither review is performed by the team that wrote the contract.
Validation and drift
Drift is only detectable on a contract that has been read against a sample.
The field list
5 fields · 1 key · 0 personal. The validation rule on each row is what admits or rejects a record at the staging boundary.
| Field | Source | Target | Type | Flags | Drift | Validation |
|---|---|---|---|---|---|---|
| Fact key | FACT_KEY | fact.ref | string(64) | keyinternal | In contract | Warehouse surrogate. Stable across reloads, which the warehouse team warrants in the contract. |
| Grain | GRAIN | fact.grain | string(40) | internal | In contract | Declared per subject area. A grain change is a contract-breaking event and must bump the version. |
| Measure value | MEASURE | fact.value | decimal(18,4) | internal | In contract | Null is not permitted. A null measure means the conforming logic failed upstream. |
| Effective date | EFF_DT | fact.effectiveOn | date | internal | In contract | Warehouse effective date, not source posting date. The two differ and the contract names the difference. |
| Load id | LOAD_ID | fact.loadRef | string(24) | internal | In contract | Idempotence key. A repeated load id is suppressed rather than re-applied. |
What has passed the staging boundary against this contract
1 batch · 44,100 arrived · 42,860 admitted · 1,240 quarantined · 0 rejected
| Batch | Arrived | In | Admitted | Quarantined | Rejected | Result | Gate |
|---|---|---|---|---|---|---|---|
| STG-0021 | Aug 18, 06:00 | 44,100 | 42,860 | 1,240 | 0 | Partly admitted | 42,860 admitted · 1,240 quarantined · 0 rejected outright. |
Rejects raised against these batches
1 reason covering 1,240 records. Each one names a field, what was observed and what the contract expected.
Replay windows
1 window recorded against this contract.
Write-back routes into this system
No write-back route is designed into this system.
What goes stale when this feed does
3 asserted figures depend on Enterprise Data Warehouse. The rule on each row is what the surface does when the feed misses its commitment.
| Figure | Where it is shown | Role | On stale | Note |
|---|---|---|---|---|
| Transactions processed each week | AI GBS towers | primary | Suppress the figure | The weekly count is read from the warehouse. Without it there is no figure to show, so the tile is suppressed rather than shown stale. |
| Cost per transaction | AI GBS towers | contributing | Mark it stale | The denominator is the warehouse transaction count. |
| Traced facts behind unit decisions | Data lineage | primary | Mark it stale | Lineage is traced through the warehouse. A stale warehouse means the trace ends at yesterday. |
A contract, a validation rule, a freshness commitment and a replay path are real mechanisms and they are what this wave builds. What they are not is a connection. No connector on this estate is attached to a customer instance, so every batch, every replay and every write-back attempt recorded here ran against a modeled extract or a sandbox, and the registry keeps saying modeled.
The last validation read 100,000 records 8 days ago, which is 4% of a single day at the declared volume. A sample proves the shape of what it read and nothing beyond it.