Ledger Data Contracts & Event Publication Policy¶


Code	`DT-012`
Domain	Data & Technology
Owner	Chief Technology Officer
Status	Draft
Applicability	Platform
Jurisdiction	NZ + AU
Business domain	BD09
Review date	2027-03-31

Purpose¶

Govern how ledger and account events are published, versioned, consumed, and evidenced across operational and analytical systems. Ensures canonical schema discipline between Neon (operational) and Snowflake (analytical) and prevents shadow extracts or uncontrolled downstream interpretations of financial data.

This is an internal architecture obligation derived from ADR-003 (CDC pipeline), ADR-036 (decision result publication), and the data governance by design principle (AP-002).

Scope¶

All ledger, account, posting, balance, and decision events published to downstream consumers including Snowflake, EventBridge, and any future analytical or regulatory reporting consumers.

Policy statements¶

Ledger publication schemas SHALL be canonical, documented, and versioned. Consumers SHALL bind to the published contract rather than inferring meaning from internal database structure.

Every published ledger or account event SHALL carry durable identifiers sufficient to link the published event back to the original source posting and originating business event.

Reason codes, decision references, state transitions, and publication timestamps SHALL be part of the published contract where relevant to downstream control or customer transparency.

Schema-breaking changes to published ledger events SHALL require an explicit version increment and a migration period for impacted consumers. No breaking change may be deployed without a coordinated consumer migration plan.

Consumers SHALL NOT create divergent recalculations of posted balances or posting semantics outside approved downstream models.

Publication to Snowflake and other downstream consumers SHALL be near real time where the architecture already supports it; operational lag thresholds SHALL be monitored and breaches SHALL trigger alerts.

Data publication failures, schema drift, and contract breaches SHALL be detectable and escalated through governed monitoring.

Satisfying modules¶

Module	Name	Mode	Description
MOD-168	Maker-checker enforcement engine	`LOG`	Every proposal, approval, rejection, and expiry is written to the system decision log (MOD-048) and the agent action logger (MOD-047) as an immutable audit record, satisfying the ledger data contracts and event publication audit obligation.

Part of Data & Technology · Governance overview Compiled 2026-05-22 from source/entities/policies/DT-012.yaml