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

> Understand intent provenance and conformance tracking in the no-mistakes pipeline. This system tracks human vs LLM origins to enforce strict review checks, halting the process on violations.

- Repository: [Kun Chen/no-mistakes](https://github.com/kunchenguid/no-mistakes)
- Tags: internals
- Published: 2026-07-18

---

**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`](https://github.com/kunchenguid/no-mistakes/blob/main/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:

```bash
$ 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`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/daemon/manager.go), the `UpdateRunIntent` method persists the source using the constant `db.RunIntentSourceAgent`:

```go
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`](https://github.com/kunchenguid/no-mistakes/blob/main/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`](https://github.com/kunchenguid/no-mistakes/blob/main/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`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/steps/intent_prompt.go), the function `intentConformanceReviewClause` builds a prompt fragment that is only appended when `isIntentSourceAgent(sctx)` returns true:

```go
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`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/steps/review.go), the conformance clause is concatenated into the final prompt:

```go
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`](https://github.com/kunchenguid/no-mistakes/blob/main/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`](https://github.com/kunchenguid/no-mistakes/blob/main/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`](https://github.com/kunchenguid/no-mistakes/blob/main/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`](https://github.com/kunchenguid/no-mistakes/blob/main/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`](https://github.com/kunchenguid/no-mistakes/blob/main/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.