# Intent Provenance and Conformance Checking in the no‑mistakes Review Step

> Understand intent provenance and conformance checking in no-mistakes review. Learn how explicit intents and inferred transcripts ensure code quality and meet user requirements.

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

---

**Intent provenance tracks whether user requirements originated from explicit CLI input or inferred transcripts, while conformance checking enforces those explicit intents as hard acceptance criteria during automated code review.**

The `no‑mistakes` pipeline extends traditional static analysis by integrating LLM‑powered review steps that validate code against user intent. Understanding how the system tracks the origin of requirements and enforces compliance is critical for teams relying on automated acceptance criteria validation.

## Understanding Intent Provenance

Intent provenance identifies the source of the "User Intent" string to determine its authority level. The pipeline distinguishes between two distinct origins that dictate how strictly the requirements are enforced during review.

### Explicit Authoritative Intent

When users supply intent directly via `axi run --intent`, the system marks the source as `db.RunIntentSourceAgent`. The function `intentSourceIsAuthoritative` in [`internal/pipeline/steps/intent_prompt.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/steps/intent_prompt.go) (lines 53‑63) evaluates this condition, treating the input as contractual acceptance criteria rather than suggestions.

### Inferred Hint Intent

Intents summarized from previous LLM transcripts carry lower confidence. Any `RunIntentSource` value other than the agent constant (such as `claude` or `codex`) signals an inferred origin. The `userIntentPromptSection` function (lines 15‑27) renders these as advisory hints rather than binding constraints.

## How Intent Conformance Checking Works

When the review step executes, it conditionally injects a conformance clause that mandates strict adherence to explicit requirements.

### Conditional Clause Injection

The `intentConformanceReviewClause` function (lines 65‑78) generates a mandatory instruction only when `intentSourceIsAuthoritative` returns true. The clause instructs the agent to emit an *ask‑user* finding if the code change contradicts any **REQUIRED** or **FORBIDDEN** criterion.

### Prompt Assembly and Enforcement

In [`internal/pipeline/steps/review.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/steps/review.go) at line 177, the pipeline constructs the review prompt by concatenating context sections:

```go
historySection := executionContextPromptSection() +
                  roundHistoryPromptSection(sctx) +
                  userIntentPromptSection(sctx) +
                  intentConformanceReviewClause(sctx) +
                  pipelineDeliveryPhaseClause()

```

If the agent violates an explicit constraint—such as removing required behavior or introducing forbidden patterns—the review step automatically parks the run with an "ask‑user" finding, preventing silent regressions even when the diff appears technically correct.

## Implementation Examples

The following snippets demonstrate how to check provenance and build conformance‑aware prompts:

```go
// Check if intent originates from explicit user input
if intentSourceIsAuthoritative(sctx) {
    // Explicit intent requires strict conformance checking
    fmt.Println("Intent is explicit – treat as acceptance criteria")
}

// Build the prompt fragment with provenance metadata
prompt := userIntentPromptSection(sctx) // Includes BEGIN/END markers

// Append conformance clause only for authoritative sources
prompt += intentConformanceReviewClause(sctx)

```

## Summary

- **Intent provenance** distinguishes between explicit CLI input (`axi run --intent`) and inferred transcript summaries, stored via `sctx.IntentSource` constants.
- **Authoritative intents** trigger hard conformance constraints, while inferred intents are treated as low‑confidence hints.
- The `intentConformanceReviewClause` function injects enforcement logic only for explicit intents, preventing false‑positive parking.
- Violations of explicit **REQUIRED** or **FORBIDDEN** criteria automatically generate "ask‑user" findings in [`internal/pipeline/steps/review.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/steps/review.go).

## Frequently Asked Questions

### How does no‑mistakes distinguish between explicit and inferred intent?

The system checks `sctx.IntentSource` against `db.RunIntentSourceAgent` using the `intentSourceIsAuthoritative` function in [`internal/pipeline/steps/intent_prompt.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/steps/intent_prompt.go). If the source matches the agent constant, the intent is explicit; otherwise, it is inferred from previous LLM transcripts.

### What happens when code violates an explicit intent requirement?

When the conformance clause is active and the agent detects a violation of **REQUIRED** or **FORBIDDEN** criteria, the review step automatically parks the run with an "ask‑user" finding. This occurs even if the code change is technically valid, ensuring explicit user requirements cannot be silently overridden.

### Why does the conformance clause only apply to explicit intents?

Inferred intents are generated by summarizing LLM conversations and carry lower confidence. Applying strict conformance checking to these hints would generate excessive false positives. The conditional injection in `intentConformanceReviewClause` (lines 65‑78) ensures only authoritative, user‑supplied constraints trigger enforcement.

### Where is the review prompt assembled in the codebase?

The final review prompt is constructed in [`internal/pipeline/steps/review.go`](https://github.com/kunchenguid/no-mistakes/blob/main/internal/pipeline/steps/review.go) at line 177, where `userIntentPromptSection` and `intentConformanceReviewClause` are concatenated with execution context and round history to form the complete prompt sent to the LLM agent.