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

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 (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 at line 177, the pipeline constructs the review prompt by concatenating context sections:

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:

// 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.

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. 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 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.

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