Intent Provenance and Conformance Tracking Mechanisms in the no-mistakes Pipeline

The no-mistakes pipeline records whether an intent originated from a human or an LLM agent, then uses that provenance to conditionally enforce strict conformance checks during the Review step that can halt the pipeline when requirements are violated.

The no-mistakes repository implements a sophisticated CI/CD pipeline that treats user intent differently depending on its origin. Understanding the intent provenance and conformance tracking mechanisms is critical for operators who need to know when the system treats requirements as hard rules versus flexible guidelines. This article examines the source code to demonstrate exactly how the pipeline records intent sources and enforces conformance through gating review steps.

How Intent Provenance Is Recorded

The Database Schema and IntentSource Column

Provenance tracking begins at the database layer. In internal/db/run.go, the Run struct contains an IntentSource column that stores a string identifying where the intent originated.

When a run is created via the CLI with an explicit intent, the source remains empty or carries a user-specific marker:

$ no-mistakes axi run --intent "REQUIRED: keep the guarded stale-lock removal. FORBIDDEN: a cleanup mutex."

However, when an LLM agent generates the intent, the daemon explicitly marks it as agent-originated. In internal/daemon/manager.go, the UpdateRunIntent method persists the source using the constant db.RunIntentSourceAgent:

if err := m.db.UpdateRunIntent(run.ID,
    db.RunIntent{Summary: trimmed, Source: db.RunIntentSourceAgent, Score: 1}); err != nil {
    // handle error
}
run.IntentSource = &source // source == db.RunIntentSourceAgent

This distinction allows downstream steps to apply different enforcement policies based on authority levels.

Propagating Provenance Through StepContext

Once persisted, the provenance flows through the pipeline via StepContext. In internal/pipeline/steps/intent.go, the intent step copies the source from the database record into the step context, making it available to subsequent phases.

The internal/pipeline/pipeline.go file contains architectural comments explaining this design choice: the IntentSource field travels with the context so that any step can query whether the current intent should be treated as authoritative (agent-generated) or advisory (human-supplied).

Enforcing Intent Conformance During Review

The Conditional Conformance Clause

The Review step uses provenance to decide whether to enforce strict conformance. In internal/pipeline/steps/intent_prompt.go, the function intentConformanceReviewClause builds a prompt fragment that is only appended when isIntentSourceAgent(sctx) returns true:

func intentConformanceReviewClause(sctx *pipeline.StepContext) string {
    if !isIntentSourceAgent(sctx) {
        return "" // No enforcement for user-originated intent
    }
    // Returns a prompt fragment that tells the reviewer to treat REQUIRED/FORBIDDEN items as hard rules.
    return "Intent conformance (required): …"
}

This clause injects specific directives into the Review-agent prompt, instructing it to treat "REQUIRED:" and "FORBIDDEN:" statements in the intent as non-negotiable constraints.

Gating Mechanism and Ask-User Findings

In internal/pipeline/steps/review.go, the conformance clause is concatenated into the final prompt:

historySection := executionContextPromptSection() +
    roundHistoryPromptSection(sctx) +
    userIntentPromptSection(sctx) +
    intentConformanceReviewClause(sctx) +   // ← adds the enforcement directive
    pipelineDeliveryPhaseClause()

When the Review agent outputs suggestions that violate these constraints, the step generates findings with action == "ask-user". These findings signal the pipeline to pause the run for human clarification rather than silently proceeding.

The internal/pipeline/steps/review_test.go file contains the test TestReviewStep_ConformanceObligationTracksIntentProvenance, which verifies that the clause appears only when IntentSource == db.RunIntentSourceAgent. A companion test, TestReviewStep_RereviewFlagsIntentContradictionAsAskUser, confirms that contradictory changes are correctly surfaced as ask-user findings that park the run.

Persistence and Downstream Availability

All provenance data remains available in the runs table schema defined in internal/db/run.go. This persistence allows external tooling and future pipeline executions to audit not just what the intent was, but who authored it.

The combination of database storage, context propagation, and conditional prompt injection creates a complete provenance chain: from CLI invocation or agent generation, through daemon persistence, to final enforcement in the Review step.

Summary

• Provenance is binary: The pipeline distinguishes only between db.RunIntentSourceAgent (authoritative) and empty/user-marked sources (advisory).
• Enforcement is conditional: The intentConformanceReviewClause function in internal/pipeline/steps/intent_prompt.go returns an empty string for human intents, effectively disabling hard enforcement.
• Gating is explicit: Violations of agent-generated intent constraints generate ask-user findings that pause the run, preventing silent regressions.
• All state is persisted: The runs table stores both intent text and source, making the full provenance available to downstream steps and external auditors.

Frequently Asked Questions

How does the pipeline distinguish between human and agent intent?

The pipeline checks the IntentSource field on the StepContext. When a human provides the intent via no-mistakes axi run --intent, the source remains empty. When an agent generates the intent, internal/daemon/manager.go calls UpdateRunIntent with Source: db.RunIntentSourceAgent, which the Review step later checks via isIntentSourceAgent().

What happens when a review violates the intent constraints?

If the intent source is agent-generated and the Review agent suggests changes that contradict "REQUIRED:" or "FORBIDDEN:" statements, the step generates a finding with action == "ask-user". This finding parks the run, requiring human intervention before the pipeline can proceed.

Where is the intent provenance stored permanently?

The provenance is stored in the runs table defined in internal/db/run.go, specifically in the IntentSource column. This value is set during the Intent step via UpdateRunIntent and propagated through the StepContext for in-memory access during pipeline execution.

Can the conformance checking be disabled for specific runs?

Yes, implicitly. Since the intentConformanceReviewClause returns an empty string when the intent source is not agent-generated, supplying a human-authored intent via the CLI effectively disables strict conformance enforcement. The intent is treated as a guideline rather than a hard specification.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}