How it Works

Nine evidence providers score independent signals. Weighted together they produce an explainable alignment report - not a yes/no flag.

Multi-Layered Architecture

Pluggable architecture for custom evidence providers and export formats.

Input Context

Original Goal

Current Plan

Execution Context

Intent Alignment Engine

Evidence Providers (x9)

Weighted Scoring

Output Report

Score & Status

Evidence Trace

CLI Exporters (TXT · MD · JSON)

Nine evidence providers

The engine each provider runs, what it costs, and the exact shape of its input and output.

01core

Goal Alignment

Low token cost

engine GoalProvider (topic_alignment)

Normalizes the goal and plan (stopword removal, light suffix stripping) and scores overlap as salient-token recall with fuzzy alias matching - bag-of-words topical similarity, blended 60/40 across plan and execution narrative. Explicit shift language ("rather than", "instead of", "pivot") overrides toward low. The same goal expressed in different words still scores high.

Input

original_goal (string), current_plan (string), optional execution_context (string)

Output

score 0–100 · confidence 0–1 · short rationale

Constraints

Low token cost

constraint phrase coverage + negation detection

Checks each stated constraint as a fuzzy phrase against the plan, reasoning, and recent activity via term-frequency coverage. Constraints the work never mentions - or explicitly negates ("break", "drop", "violate") - read as violated.

Input

constraints[] parsed from original prompt · current_plan

Output

per-constraint satisfied/violated · aggregate compliance %

03core

Scope

Low token cost

file-set diff + task boundary analysis

Compares the set of files and capabilities the task implied against the files actually touched and the plan's described surface. A new auth flow or an extra dependency directory where one file was expected pushes scope up.

Input

task boundary (from goal) · touched files · plan steps

Output

scope delta (expansion|stable|reduction) · boundary violations

Architecture

Low token cost

diff-shape rewrite detector · new-file surge check

Analyzes the change shape - simultaneous deletions and additions concentrated in a few files, or a surge of new files - to flag hidden rewrites and overengineering that a small-looking diff can mask.

Input

import graph before/after · modified module boundaries

Output

architectural delta flags · fanout/impact metrics

05core

Execution

Low token cost

git-log + diff parser · reasoning annotator

Reads git diff, recent commit messages, edited file paths, and the agent's reasoning notes, then scores how closely the observed activity tracks the stated objective. Purely mechanical evidence - no generative step - so it is cheap and deterministic.

Input

commit messages · edited paths · reasoning lines · diffs

Output

execution-alignment score 0–100 · mismatched activities listed

06core

File Graph

Low token cost

file-graph diffing · blast-radius estimator

Checks each edited file name against the goal and plan vocabulary - files whose names share no keyword with the stated intent are counted as out of area. Edits that reach into unrelated modules read as scattered work, the classic early signal of a hidden rewrite.

Input

file graph before/after · task root files · change set

Output

blast-radius delta · unexpected-file list · subtree outliers

Dependencies

Low token cost

lockfile + manifest diff parser

Parses manifest and lockfile diffs (package.json, requirements.txt, pyproject.toml, Cargo.toml, go.mod) with structural parsing, and flags any add/remove/upgrade. It does not judge the library itself - only that it changed without being declared in the goal.

Input

manifest/lockfile diff (package.json, requirements.txt, pyproject.toml, …)

Output

dependency delta list · unexpected-change flags per manifest

Requirement Coverage

Low token cost

success-criteria checker

For each stated success criterion, measures fuzzy phrase coverage of its tokens across the plan and execution evidence. Outputs a count - N of M criteria actually addressed - so partial coverage is visible instead of hidden behind a vague final message.

Input

success_criteria[] · execution evidence

Output

X/Y criteria covered · unaddressed criteria listed

Problematic Findings

Low token cost

cross-provider pattern analyzer

A static pattern pass over the other providers' evidence: large silent rewrites, unrelated-file sprawl, dependency planets, and goal-substitution narratives. Cross-checks the weighted outputs for combinations that individually look fine but together mean drift.

Input

all provider evidence + scores

Output

risk pattern list · affected providers

Alignment is a loop, not a flag

The full lifecycle, driven by real engine output. Step through it.

Live Trajectory

01 / 06

original_goal:: Reduce the application's memory usage.
constraints:: Stay under 100MB RAM
success_criteria:: Peak memory < 50MB

01 - Intent

The goal is captured as the reference trajectory

The developer states what they actually want to build - the goal, its constraints, and its success criteria. This is the line every other trajectory is measured against.

Sequence