Skip to content

Chapter 4: Quality and Governance

Learning Objectives

By the end of this chapter you will be able to:

  1. Distinguish between quality gates and constitutions and explain when each applies.
  2. Describe the three-tier governance model (hard-stop, mandatory, preferred).
  3. Explain how the Constitution Registry maps governance rules to individual personas.
  4. Trace the path an artifact takes through quality evaluation, from gate definition to pass/fail outcome.
  5. Articulate why trust in multi-agent systems requires explicit, auditable governance.

The figure below shows the governance pipeline an artifact traverses after the Create phase, from schema validation through constitution compliance to quality-gate evaluation.

flowchart TD
    ART[Artifact from Create Phase] --> SV{Schema<br/>Validation}
    SV -->|Invalid| REJ[Reject]
    SV -->|Valid| CC{Constitution<br/>Compliance}
    CC -->|Hard-Stop Violation| HALT[Halt + Escalate to Human]
    CC -->|Mandatory Violation| WARN[Warning + Re-create]
    CC -->|Pass| QG{Quality Gate<br/>Evaluation}
    QG -->|Below Threshold| FB[Feedback Loop]
    QG -->|Above Threshold| PASS[Approved]

    style REJ fill:#d32f2f,color:#fff
    style HALT fill:#d32f2f,color:#fff
    style PASS fill:#4CAF50,color:#fff
    style WARN fill:#FF9800,color:#fff

The three-tier structure means policy authors can tune the severity of each rule without rewriting the pipeline. Moving a rule from mandatory to hard-stop is a single attribute change in the constitution registry.

The Trust Problem

When a human team produces a deliverable, trust is built through years of professional relationships, shared standards, and institutional memory. When an AI-agent team produces a deliverable, none of those trust mechanisms exist by default. The agents have no memory of past collaborations, no professional reputation, and no implicit understanding of "how we do things here."

FCC addresses this by making trust mechanisms explicit and machine-enforceable. Two complementary systems provide the foundation:

  • Quality gates define measurable thresholds that artifacts must pass.
  • Constitutions define behavioral rules that personas must follow.

Together, they ensure that the outputs of the FCC cycle meet both technical quality standards and organizational governance requirements.

Quality Gates

A quality gate is a named checkpoint with a measurable condition. The FCC framework ships with 25 pre-defined quality gates in src/fcc/data/governance/quality_gates.yaml. Each gate specifies:

  • Name: A human-readable identifier (e.g., "test_coverage_minimum").
  • Description: What the gate checks.
  • Threshold: The numeric or boolean condition for passing.
  • Severity: What happens on failure -- block (hard stop), warn (log and continue), or inform (note for review).
  • Applies to: Which workflow phases or persona categories the gate covers.

Example Gates

Gate Threshold Severity
test_coverage_minimum >= 95% line coverage Block
documentation_completeness All public APIs documented Warn
security_scan_clean Zero high-severity findings Block
style_guide_compliance Zero lint violations Warn
stakeholder_approval At least one approval from stakeholder persona Block

Gates are evaluated by the scoring engine (src/fcc/collaboration/scoring.py), which takes an artifact and a list of applicable gates and produces a structured result: pass, fail, or conditional pass with warnings.

Gate Composition

Gates can be composed. A "release readiness" meta-gate might require that all of the following sub-gates pass: test coverage, documentation completeness, security scan, and stakeholder approval. The composition is declarative -- you define which gates compose the meta-gate, and the scoring engine evaluates them in dependency order.

Constitutions

Where quality gates measure outputs, constitutions constrain behavior. A constitution is a set of rules that a persona must follow regardless of what it is working on. Constitutions capture organizational values, ethical principles, and process requirements.

The FCC framework uses a three-tier governance model:

Tier 1: Hard-Stop Rules

These rules cannot be overridden. If a persona violates a hard-stop rule, the workflow halts immediately and escalates to a human reviewer. Examples:

  • "Never generate content that could be used for harm."
  • "Never access data outside the project's authorized scope."
  • "Never bypass a blocking quality gate."

Hard-stop rules are the framework's ethical floor. They exist because some constraints are not negotiable, regardless of the task's urgency or the stakeholder's preferences.

Tier 2: Mandatory Rules

These rules must be followed unless a documented exception is approved by a governance persona. Violations trigger a review workflow but do not halt the system. Examples:

  • "All code must include error handling for external API calls."
  • "All data processing must log its lineage."
  • "All recommendations must cite their source findings."

Mandatory rules encode organizational best practices. They are strict but not absolute -- there are legitimate cases where an exception is warranted, and the framework provides a mechanism to document and approve those exceptions.

Tier 3: Preferred Rules

These rules represent guidelines that personas should follow but may deviate from when the task context requires it. Violations are logged but do not trigger review. Examples:

  • "Prefer structured output over prose."
  • "Use the standard template for reports."
  • "Include executive summary for documents over 1,000 words."

Preferred rules capture team conventions. They reduce variability without creating rigidity.

The Constitution Registry

The ConstitutionRegistry (src/fcc/governance/constitution_registry.py) maps governance rules to individual personas. Each persona has a PersonaConstitution that lists the hard-stop, mandatory, and preferred rules applicable to that persona.

The registry supports:

  • Per-persona lookup: "What rules apply to the Ethics Auditor?"
  • Per-rule lookup: "Which personas are subject to the data lineage rule?"
  • Tier filtering: "Show me all hard-stop rules across all personas."
  • Inheritance: A champion persona inherits the constitutions of all personas it orchestrates, plus its own.

This per-persona mapping is important because not all rules apply to all personas. A Data Engineer needs data lineage rules; a Technical Writer does not. The Constitution Registry makes these distinctions explicit rather than relying on agents to self-select which rules they follow.

Tags and Compliance

The governance subsystem also includes a tag registry (src/fcc/data/governance/tag_registry.yaml) with 30 tags organized by capability, category, and supercategory. Tags provide a lightweight classification system for artifacts, personas, and workflows. They enable queries like "show me all artifacts tagged security" or "which personas are tagged data-engineering?"

Tags feed into compliance reporting. A compliance dashboard can show which quality gates have been evaluated, which constitutions are in effect, and which tags have been applied, giving stakeholders a single view of the project's governance posture.

The Governance Workflow

When governance is active, every Create node in the workflow graph has an implicit governance checkpoint. The flow is:

  1. Create node produces an artifact.
  2. Quality gates are evaluated. The scoring engine checks all applicable gates.
  3. Constitution compliance is verified. The constitution registry checks that the creating persona followed its assigned rules.
  4. If all gates pass and all rules are respected: The artifact proceeds to the next node.
  5. If a gate fails or a rule is violated: The response depends on the severity tier.
  6. Hard-stop: Workflow halts, human escalation.
  7. Mandatory: Feedback edge triggers re-creation with the violation noted.
  8. Preferred: Violation is logged, artifact proceeds.

This governance workflow is transparent. Every evaluation is recorded in the event bus (Chapter 5 of this book and Book 2, Chapter 6), creating an audit trail that stakeholders can inspect.

Why This Matters

In production AI systems, the question is not "can the agent do the task?" but "can we trust the agent's output?" Quality gates and constitutions provide an answer that is verifiable, auditable, and consistent. They turn trust from a subjective judgment into an objective measurement.

This is especially important when FCC is used in regulated industries (healthcare, finance, government) where compliance is not optional and audit trails are legally required.

Key Takeaways

  • Quality gates define measurable thresholds for artifacts; 25 are pre-defined.
  • Constitutions define behavioral rules for personas using a three-tier model: hard-stop, mandatory, preferred.
  • The Constitution Registry maps rules to individual personas with per-persona lookup and inheritance.
  • Tags provide lightweight classification for compliance reporting.
  • Every governance evaluation is recorded in the event bus, creating an audit trail.
  • The governance workflow is integrated into the graph traversal, not bolted on as an afterthought.

Cross-References

← Chapter 3: Workflow Thinking | Next: Chapter 5 -- The Collaboration Model →