Part 6. Constitution of the Bank's Data Platform

The constitution of the data platform answers the question: which decisions do not need to be discussed again in every mart. In the base volume, the constitution fixed the mission, stack, and roadmap of the application. Here it fixes the mission of DataLakeHouse, the local stack, the mapping boundaries with the production environment, the PII policy, and the rules for changing contracts.

Minimum files

specs/mission.md
specs/tech-stack.md
specs/roadmap.md
AGENTS.md

mission.md explains why the platform exists. tech-stack.md says which tools are allowed. roadmap.md shows the order of artifacts. AGENTS.md sets the rules of behavior for the agent.

What should be in the mission

A good mission for an educational bank:

The platform builds reproducible analytical marts for the educational bank.
Every data product must have an owner, a consumer, a grain, a PII policy,
a freshness promise, verification facts, and a reviewer report.

A bad mission:

Build a modern banking data platform.

It sounds grand, but it doesn't help the agent make a decision.

Non-negotiable rules

Write down the rules that cannot be changed within an individual mart:

• marts do not expose direct PII fields;
• changing the grain requires approval;
• mandatory contract fields cannot be removed without a note about a breaking change;
• dbt build --profiles-dir . is a mandatory check, if dbt

is available;

• the reviewer's pass must not edit files.

If such a rule appears for the first time during implementation, stop and update the constitutional file before continuing with SQL.

Breakdown for the reader

The constitution of a data platform seems high-level until the first conflict appears. The agent wants to add a convenient column. The analyst asks for more detail. The mart begins to expose a field that was previously considered technical. If the project does not have a short set of principles, each such decision is made anew, often in favor of the nearest task. The constitution is needed so that the nearest task does not break the long-term meaning of the data.

Unlike a regular technology stack, the constitution says not only "what tools we use", but also "what decisions the agent does not make on its own". For banking data, this is especially important. Grain, PII policy, SLA, breaking changes, and the risk methodology should not appear as a side effect of SQL.

If the agent proposes to change one of these points, it must stop and ask for confirmation, rather than explaining the change after the fact.

A good constitution is short, but verifiable. A bad one says: "maintain quality and security". A good one says: "marts do not expose direct PII", "changing the grain requires human confirmation", "verification facts are written before SQL". Such rules can be applied in review. If a rule cannot be verified, it remains a slogan and does not help the agent.

It is useful for the reader to treat the constitution as a contract with their future self. At the beginning of the project everything seems obvious: Customer 360 is one row per client, consents are counted separately, the risk flag is educational. After ten changes the obviousness disappears. The constitution preserves the original decisions in a place where the next agent pass and the next reviewer will see them.

Practice

Formulate five non-negotiable rules for your data platform. For each rule, specify where it lives: AGENTS.md, mission.md, tech-stack.md, contract YAML, or the model specification.

Qwen prompt

Help me compose the constitution of an educational bank's data platform.

Before writing files, ask questions about the mission, stack, PII policy, contract drift,
and human confirmations.
Do not write SQL.

Minimum output

After the chapter:

• specs/mission.md describes the purpose of the platform;
• specs/tech-stack.md fixes the local stack and the mapping with the production environment;
• specs/roadmap.md guides through the artifacts;
• AGENTS.md prohibits PII leakage and unapproved contract drift.

Typical mistake

Mixing the constitution with the specification of a specific mart. mission.md should not list SQL fields of mart_customer_360; the model specification should not re-select DuckDB or dbt.

Control questions

1. Which decisions should live in the constitution, and which in the model specification?
2. Why is it better to fix the PII policy before profiling the sources?
3. When does changing a contract field require separate approval?