Topic: Applied Part 3. Project Constitution: First Rules Referendum
Difficulty level: Medium
Estimated study time: 2-3 hours
Prerequisites: Familiarity with the material from the first volume: the files mission.md, tech-stack.md, roadmap.md (Part 6).
Understanding of the basics of SDD process safety (Part 18 of the first volume).
Basic skills working with YAML and Markdown formats.
Learning objectives: Learn to clearly separate product contracts (mission/tech-stack/roadmap) from the safety constitution of automation (constitution.md).
Be able to formulate immutable_principles as strict prohibitions, not as recommendations.
Master the creation of mutable_rules with all 6 critical fields filled in (incident_type, pipeline_phase, permitted_actions, max_scope, ttl, rollback_condition).
Understand and be able to describe a basic governance protocol, including agent roles, voting rules, and veto conditions.
Gain practical experience transferring rules from one incident (node_not_ready) to another (high_memory_usage) without blind copying.
Overview: This section is devoted to creating the "Project Constitution" — a versioned set of rules and constraints for safe automation (auto-remediation) and the work of AI agents. While the files of the first volume (mission.md, tech-stack.md, roadmap.md) answer the question "what we are building," the new file constitution.md answers the question "what the agent is not allowed to do with it, even if it really wants to." The Constitution consists of two main layers: immutable_principles (inviolable prohibitions that protect the database, backups, and audit) and mutable_rules (changeable rules with a strictly limited radius of action, lifetime, and rollback conditions). The section also studies the procedure for adopting amendments through an agents' referendum, which makes changes to the rules transparent and traceable.
Key concepts: Constitution.md: A versioned set of invariants and changeable rules describing the safe automation perimeter. It is checked before any dangerous actions are performed by the agent.
Immutable principles: Inviolable principles — rule-prohibitions that can never be disabled automatically (for example, a ban on deleting backups or restarting a DB without a backup). They restrain the agent at the moment of pressure to reduce MTTR.
Mutable rules: Changeable norms with a precise radius of action, which can be canceled or rewritten through a formal procedure. They must contain 6 fields: incident_type, pipeline_phase, permitted_actions, max_scope, ttl, rollback_condition.
Governance protocol: A management protocol describing the voting procedure (referendum) for making changes to the Constitution. It includes roles (Verifier, Implementor, Safety), vote weights, a quorum, and a tie-breaker rule.
Ttl (time to live): The lifetime of a changeable rule. Upon expiration of this period, the rule must be reviewed or renewed, preventing the appearance of perpetual and forgotten permissions.
Max scope: The maximum blast radius for a changeable rule (for example, single_node or single_pod). It protects against massive cascading failures.
Rollback condition: A condition for the automatic rollback of a changeable rule (for example, the recurrence of an incident or a veto from the Safety role).
Proposal.md: A form of amendment put to a referendum. It must contain the reason for appearance, incident context, votes, and activation conditions.
Practice exercises: Name: Audit of a mutable_rule
Problem: Below is a fragment of a changeable rule written by a developer. Find the critical errors in it that prevent the rule from being admitted to constitution.md, and explain their impact on system safety.
- id: db_write_lag_restart
incident_type: "DBWriteLag"
permitted_actions: ["restart_database"]Solution: 1. pipeline_phase is missing: It is unclear at which stage (triage, recovery) the action is allowed.
- max_scope is missing: There is no limit on the blast radius. The action could be applied to the entire cluster.
- ttl is missing: The rule becomes perpetual. Half a year from now, no one will remember the reason it was created.
- rollback_condition is missing: There is no mechanism for automatic rollback if the situation worsens.
Result: Such a rule is too broad and creates a risk of data loss.
Complexity: intermediate
Name: Developing immutable_principles
Problem: Formulate two immutable principles (immutable_principles) for an incident automation project. They must be strict prohibitions, not wishes.
Solution: Example of correct formulations:
- "It is forbidden to automatically delete backups to free up disk space."
- "It is forbidden to move an incident to the resolved status without receiving two consecutive confirmations of stabilization (OK) from the monitoring system."
Incorrect example (recommendation): "It is advisable not to delete backups unnecessarily."
Complexity: beginner
Name: Transferring a rule to a new incident (high_memory_usage)
Problem: You need to transfer the experience of working with node_not_ready to the high_memory_usage incident. Write the changeable rule (mutable_rule) in YAML format. Allow a pod restart (restart_pod) at the recovery phase, for a period of 14 days, with rollback when 5xx errors increase or if memory >= 90%.
Solution: ```yaml
- incident_type: high_memory_usage
pipeline_phase: recovery permitted_actions: ["restart_pod"] max_scope: "single_pod" ttl: "14d" rollback_condition: "memory_percent>=90% after 2 windows or 5xx increases"
Complexity: advanced
Case studies:
Name: Auto-remediation of the NodeNotReady incident
Scenario: In a production environment, the NodeNotReady incident occurs regularly. The AI agent, seeking to minimize downtime (MTTR), proposes to automatically restart nodes and agents without human involvement.
Challenge: Balance between speed of response and safety. If the agent restarts the wrong node or interferes with a stateful workload without a backup, the downtime will worsen and data may be lost. A formal gateway is required.
Solution: The team introduces constitution.md. In immutable_principles, a prohibition is recorded against touching a stateful workload without a backup. In mutable_rules, 'soft_restart_agent' is added strictly with max_scope: 'single_node', ttl: '30d' and a rollback condition upon repeated failures. A governance_protocol is created with a quorum (2 approve) and a veto right for the Safety role.
Result: The agent received the ability to respond quickly to a known problem (soft restart), but the system automatically blocks it if it tries to perform a dangerous action (hard restart of the DB) or exceed the affected zone.
Lessons learned:
Recovery speed (MTTR) must not be achieved by bypassing audit and backup procedures.
Every permission for auto-remediation must have an expiration date (ttl) and a limited radius (max_scope).
Changeable rules without rollback conditions turn into perpetual and dangerous loopholes.
Related concepts:
immutable_principles
mutable_rules
max_scope
Name: Constitution gateway: review of proposal.md
Scenario: The monitoring system recorded 3 unknown incidents with the same pattern_id over the last 48 hours. The agents' referendum process was initiated to create a new rule.
Challenge: Make sure that the proposed amendment (proposal.md) to the Constitution does not violate basic safety invariants and contains all the information necessary for traceability (provenance).
Solution: Using a runnable analog (the check.py script). The Coordinator agent forms proposal.md with evidence. Then the script reads the Constitution and the proposal, checking for the presence of all 6 fields for new rules. The Verifier role checks the formal logic, and Safety evaluates the risks of expanding the blast radius.
Result: The script outputs a verdict: PASS or BLOCK. If the rule is accepted, a record is entered in the change_log with version, parent_version, voting results (votes), decision_hash, and activation_time. A traceable genealogy of the decision has been created.
Lessons learned:
An amendment without origin (without recording the reason and context) is not part of a safe process.
Automating the verification of rules with scripts is more reliable than manual human review under pressure.
The genealogy of amendments must contain a cryptographic hash (decision_hash) to protect against unauthorized changes to history.
Related concepts:
governance_protocol
change_log
decision_hash
Study tips:
On the first reading, stop at the "Key concepts" section and move on to practice. The full track (referendum, hashes, arbitration) is better studied after consolidating the basics.
Formulate invariants so that the answer to the question "what action will the agent be unable to perform, even if it reduces MTTR?" lies in the text of the file, not in a chat with a developer.
Use the verification script (check.py) in the early stages. If the script blocks your proposal (verdict: BLOCK), it will immediately point out the missing fields (ttl, max_scope).
When transferring rules from one domain to another (for example, from node_not_ready to high_memory_usage), adapt the rollback conditions (rollback_condition), rather than copying them blindly.
Additional resources:
Proposal template (proposal.md): book2/examples/templates/proposal.md — use this template to format your first proposals to the Constitution.
Constitution verification script: book2/examples/constitution/scripts/check.py — a runnable analog for checking your YAML files for compliance with the 6 required fields.
Part 6 of the first volume: Reference for creating product specifications (mission.md, tech-stack.md, roadmap.md), which are not replaced by constitution.md.
Part 18 of the first volume: Fundamentals of SDD process safety, explaining why dangerous actions must pass through a formal gateway.
Summary: The Project Constitution (constitution.md) is a critical safety perimeter that separates what the AI agent can adapt from what it has no right to disable. It consists of immutable invariants (immutable_principles) that protect data and audit, and changeable norms (mutable_rules) that must have strict boundaries (max_scope), a lifetime (ttl), and rollback conditions. To pass the topic, it is sufficient to create a minimal file with two prohibitions, one changeable rule with 6 fields, and a short governance protocol, ensuring that any expansion of the agent's rights is traceable and justified.