Fact Register

Why a register of facts

Rates, regulations and provider terms change. A WhatsApp rate card moves, an API scope needs new approval, a tax rule changes, a model licence adds a restriction. Products built on stale facts make bad decisions. The Fact Register exists so One3 never launches or decides on a fact nobody has checked.

How it works

Each fact has an id, the claim, a category, source type and source, owner, last verified date, expiry date, affected documents, what decision is blocked if it is false, and a status. Work that depends on an unverified blocking fact is marked Done-pending-fact. Owners get expiry alerts 14 days before a fact expires.

Gates, not notes

Planned for Wave 2: BlockedDecision links connect each fact to the features, feature flags, connectors, models, Actions and templates that depend on it, and enforce gates. A feature flag stays off, a connector stays out of production, a model stays unroutable. When a fact changes, a change impact review creates tasks on affected docs and features within five working days. A gate review report shows that every launch-blocking fact is verified or waived in writing. Rate and price facts, such as the WhatsApp rate card or model prices, feed metering with effective dates. A regulatory watch cadence runs weekly triage, a monthly expiry sweep and a quarterly review.

Internal first

The register is internal to One3 in Year 1, starting with at least 30 rows and a CI check that every "verify" in an architecture decision links to a fact id. An internal web screen follows in Wave 2.

Planned for Wave 3: AI assistance that detects new "verify" statements and drafts fact rows for owner review (never auto-verifying), and tenant-visible facts such as current pass-through rates, the sub-processor list and certification status. In Wave 4, tenants are planned to run their own fact registers through the GRC module.