Skip to content

Library · Data Practice OS

Decision register

Decision record · Published · Source reviewed

The register is the index of decisions: one row per significant architecture choice, linking to the Options paper that analysed it and the ADR that records it. The format follows a platform team's Snowflake and legacy-system decision registers (created 30 Oct 2026, now Confluence databases).

Status rules

Decision status is separate from document status and from delivery status. Publishing a page, assigning a person or starting the build does not approve anything.

Decision status Meaning
Proposed A recommendation exists. The accountable role has not approved it
Under review The accountable role is reviewing it
Accepted The accountable role approved it. Record the date and the approval evidence
Rejected Rejected. Record the reason
Deferred Postponed. Record the condition for review
Superseded A later accepted decision replaces it. Link the replacement
  1. One row for each significant architecture choice.
  2. Link the options paper and/or ADR.
  3. Before acceptance, record the accountable role, the approval evidence and the decision date.
  4. Track implementation in delivery work, not in the decision status.
  5. Write claims in other pages with the status attached, for example "Iceberg for data that crosses engines (proposed, ADR-002: Apache Iceberg as the interchange table format)". Do not state a proposed decision as practice.

Decisions

ADR Status Proposed accountable role
ADR-001: One platform by default, two only by workload Proposed Enterprise architecture board
ADR-002: Apache Iceberg as the interchange table format Proposed Solution architect
ADR-003: dbt as the transformation standard Proposed Solution architect
ADR-004: One catalog of record per table Proposed Solution architect
ADR-005: Governed model access through an AI gateway Proposed Security reviewer, with the AI governance forum
ADR-006: Define metrics once in a semantic layer Proposed Solution architect

Open questions

Raised but not yet framed as a decision. No recommendation is implied.

Question Raised by Status Where it matters
System of record for classification: the identity vendor's sensitivity labels (for example Purview) or the data platform's tags (Horizon, Unity Catalog)? Which one wins when they disagree, and which way they sync The source draft 90-Day Implementation Plan (5 Nov 2026) assumes Purview labels. The organisation has not decided, and the platform itself is not decided Open Security foundations, the first 90 days, Governance, security and trust, ADR-004: One catalog of record per table

A platform team keeps its own registers for platform-level choices. At the time of review (6 Nov 2026), none of these was accepted:

The platform team decision (options paper) The platform team recommendation Where it informs this practice
Snowflake infrastructure as code: Terraform vs DCM Terraform only, moved in steps (57/66) Infrastructure as code for the data platform
Database and schema layout Shared raw database, one model database per environment (65/75, a tie) Naming conventions
Raw storage: managed tables vs Iceberg Managed tables; Iceberg per source on named triggers (58/63) ADR-002: Apache Iceberg as the interchange table format, Apache Iceberg as the interchange format
Pipeline code: explicit vs metadata-driven Split by layer (54/63) Pipeline code - explicit vs metadata-driven
Hosting MCP services in AWS FastMCP on Fargate first; AgentCore Gateway as the target Agents and MCP
Agent memory Not ready for a decision Agent memory
Organisational knowledge access Not ready for a decision RAG and enterprise search
Executable rules Not ready for a decision Where business rules run after migration

Who decides

Use RACI, with one Accountable role per decision. The roles and matrix are in Operating model.