I Built IntentChord to Bring Human Control to AI Coding Agents — Contributors Welcome

The central principle is the part most agent tooling skips — a successful-looking response answers none of the four questions you list, especially whether the change stayed in approved scope. Execution contracts plus evidence-based review is a stronger shape than another approval popup, because the human judges evidence, not prose. How do you handle scope drift mid-task — does the contract freeze, or can the agent renegotiate scope with evidence attached?

Great question — and this is an important distinction in IntentChord.

Scope Confirmation is a hard authority freeze, not a flexible instruction the agent can rewrite mid-task.

If an agent discovers that it needs a file or action outside the confirmed scope, it must stop and explain:

What additional access is needed
Why it's necessary
What evidence supports the proposed expansion

But that evidence does not grant permission.

The agent cannot inspect or modify the additional files until the owner explicitly authorizes a new scope.

IntentChord preserves the original confirmed scope and run history rather than silently modifying their authority. Any approved change requires an explicit rebase and scope re-confirmation through the backend. An active run cannot simply renegotiate its own permissions.

The backend also checks current source authority against the frozen context before allowing new execution. Source drift requires re-confirmation rather than implicit acceptance.

So the distinction is: the agent can propose a scope change with evidence, but only the human can authorize it — through a new confirmed authority boundary.

That's a central part of why we separate agent intent, execution authority, evidence, and the final owner decision.

The hard-freeze answer is cleaner than I expected — the agent can propose with evidence but can't spend it, and the backend re-check against the frozen context closes the drift loophole I was worried about. The part I'd still probe is the stop itself: when the agent halts mid-task to ask, does the run resume cleanly after re-confirmation, or does the rebase cost it the work it already did?

That's a very fair question — and there's a deliberate trade-off here.

IntentChord preserves the previous run, its evidence, findings, and decision history. A scope rebase doesn't erase that history or automatically roll back existing workspace changes.

However, it does not silently resume the old run under expanded permissions.

Once the owner resolves the stopped run and explicitly re-confirms the new scope, execution continues through a new, lineage-linked run using the newly approved contract.

There is an important distinction in what carries forward:

Under the exact same execution authority, a correction run can inherit eligible previously verified checks.
After an authority-changing rebase, previous evidence remains available as historical provenance, but it is not automatically treated as verified under the new contract. The new run must establish the required trusted evidence again.

So the work isn't simply forgotten, but neither do we claim seamless restoration of an agent's live session or zero-cost continuation.

That distinction is intentional: preserving progress and preserving authorization are different problems. We're particularly interested in improving the continuation experience without weakening the evidence and authority boundaries.

The lineage-linked run is the right compromise — progress survives, but authorization doesn't get smuggled across the rebase, and re-establishing trusted evidence under the new contract is the price of that honesty. The cost question is where it bites in practice: does the new run re-verify everything, or only the checks that depend on the expanded authority? If it's the latter, the rebase stays cheap; if it's everything, a late scope change gets expensive fast.

You're absolutely right — and I think you've identified a genuinely valuable improvement opportunity.

To answer directly: today, IntentChord does not perform selective revalidation across an authority-changing rebase. Previously trusted checks remain preserved as historical evidence, but the new run must establish fresh trusted evidence under the new contract.

That doesn't necessarily mean redoing all the implementation work. The distinction is between preserving completed work and proving that its validation is still applicable.

You're right that this can become expensive, especially when a late scope expansion affects only a small part of the task.

The encouraging part is that IntentChord already has some foundations we could build on:

Run lineage and historical evidence provenance.
Workspace revisions and source deltas.
Correction inheritance for eligible trusted checks when the execution authority remains identical.

What's missing is a reliable way to establish which checks are genuinely unaffected by an authority change — including their source dependencies, execution context, and indirect dependencies.

That makes dependency-aware revalidation a particularly interesting direction: preserve the authority boundary, but avoid repeating validation when its continued validity can be independently demonstrated.

I made IntentChord available for contributions precisely because discussions like this can reveal ways to improve the system without compromising its principles.

I'd be interested in your take: how would you approach proving that a check remains valid across a scope expansion, particularly when indirect dependencies are involved?

Thanks for raising this. It's exactly the kind of practical engineering question worth exploring.

Dependency-aware revalidation sounds like the right direction, and the test I'd start with is intersection: a check carries over only if none of its inputs — files, tool permissions, environment — intersect the expanded scope, verified by hash rather than by name. The indirect part is the hard bit, because a check can depend on something it never named, so provenance has to be captured at run time, not reconstructed afterwards. I'd start narrow: deterministic, pure checks first, where re-running is cheap to verify, and keep stateful or side-effecting checks on full revalidation until that provenance is trustworthy. Does the lineage already record enough to compute that intersection, or would that be the new piece to build?

That's an excellent distinction, and I particularly like your suggestion to start with deterministic, pure checks rather than trying to solve every kind of validation at once.

To answer your question directly: the lineage doesn't yet capture enough to safely compute that intersection. That would be the new piece to build.

IntentChord already preserves parent/child run relationships, contract revisions, trusted validation evidence, source content hashes, and tool authorization traces.

But those records don't currently form a complete, runtime-captured dependency footprint for each individual check — covering its actual file inputs, relevant permissions, execution environment, and indirect dependencies.

So today, correction inheritance remains conservative: eligible checks can be inherited under the exact same execution authority, but an authority-changing rebase requires fresh trusted evidence.

I think your approach provides a sensible path forward.

One important distinction I'd preserve is that matching hashes prove the identity of observed inputs, not that every relevant dependency was actually observed. If dependency coverage is incomplete or uncertain, the system should fall back to revalidation.

Starting with deterministic checks, capturing their dependencies during execution, and keeping stateful or side-effecting checks on full revalidation sounds like a strong way to explore this without weakening the trust boundary.

This is exactly the kind of technical input I hoped opening IntentChord to contributors would encourage.

I'd genuinely be interested in how you'd approach capturing that runtime dependency footprint across different agent execution environments.

The hash-versus-coverage distinction is the key one — matching hashes prove the inputs you saw didn't change, not that you saw all of them. That pushes capture down to the runner rather than the agent's own report: if the footprint is recorded by whatever actually executes the check — file opens, tool calls, env reads — an unobserved dependency is a gap in the tracer, not a claim the agent forgot to make. Is there a portable layer for that across environments, or does each runner need its own tracer before the footprint is trustworthy?

That's exactly the right question, and I think the distinction is between a portable evidence and trust contract and a portable capture mechanism.

IntentChord already has a substantial foundation for the first part.

The current architecture includes a canonical Workspace Index with source identities, revisions, hashes, facts, and relationships; AI Context Mapping for understanding dependencies and identifying evidence gaps; and backend-governed execution contracts, run lineage, and evidence verification.

It also supports run-bound evidence ingestion from signed harnesses and adapters, with producer authentication, replay protection, and independently evaluated validation and tool traces.

But there's an important boundary: those mechanisms establish the provenance and integrity of submitted evidence. They don't automatically prove that every dependency used by an executing check was observed.

So the honest answer is that IntentChord doesn't yet have a complete, portable runtime dependency tracer with coverage attestation.

The direction I'd explore is to preserve the existing backend-owned evidence authority while separating two responsibilities:

A common evidence contract: check identity, execution authority, observed dependencies, content fingerprints, environment and permission context, capture capabilities, and explicit coverage limitations.
Runtime-specific capture implementations: using the mechanisms available in each execution environment, without assuming that one tracing technique provides equivalent guarantees everywhere.

That wouldn't necessarily require a separate tracer for every individual runner. Multiple runners could share an implementation where its capabilities and coverage guarantees are demonstrably sufficient.

And I agree with your core point: an unobserved dependency must never be interpreted as proof of independence. If capture completeness cannot be established, the result shouldn't qualify for selective inheritance.

This also fits IntentChord's existing conservative correction policy: trusted checks can currently be inherited under the exact same execution authority, while an authority-changing rebase requires fresh evidence.

Your proposal suggests a possible way to make that more selective in the future, without weakening the authority boundary.

One question I'd be interested in exploring with you: would you define capture coverage as a set of explicitly qualified capabilities per execution environment, rather than trying to certify an entire runner as universally trustworthy?

Yes — qualified capabilities per environment, not a universal runner certification. A runner that can trace file opens but not env reads shouldn't carry the same coverage claim as one that traces both, and the contract should carry that gap explicitly so the rebase decision sees it. The part I'd still want pinned down: who writes the qualification — the runner's own claim, or an independent check that verifies the tracer actually caught a planted dependency?

I'd put qualification on the independent verification side, not let the runner certify itself.

The runner or tracer can declare what it supports, but that declaration should be treated as a capability claim, not evidence that the capability works.

Interestingly, IntentChord's existing architecture already makes a similar distinction in its Capability Registry: declared capabilities are separate from empirically demonstrated capabilities. That principle currently applies to intelligence connectors, but I think it translates naturally to runtime tracing.

For dependency capture, I'd distinguish three things:

Declared capabilities: What the tracer claims it can observe — file access, environment reads, subprocess activity, etc.
Independent qualification: Controlled tests with known, deliberately introduced dependencies verify which capabilities the tracer actually detects, under a specific platform, version, configuration, and execution boundary.
Per-run coverage evidence: Each actual check execution records which qualified capture capabilities were active, whether the observation remained intact, and any gaps or failures.

The Backend should evaluate those records against the evidence policy. A signed runner report alone shouldn't be able to promote its own coverage claims into trusted qualifications.

There's also an important limit: passing planted-dependency tests establishes demonstrated coverage for specific scenarios, not universal completeness. Anything outside the qualified boundary remains unknown, and unknown coverage should never justify selective evidence inheritance.

IntentChord already has the backend-owned evidence and authority foundations for this separation. The independent tracer qualification and per-check coverage attestation would be additional capabilities to connect to that foundation, rather than a replacement for it.

That keeps the trust boundary consistent: the component performing the work can produce observations, but it doesn't get to decide whether those observations are sufficient proof.

Independent qualification is the only version of this that holds — a tracer declaring its own coverage is just a capability claim wearing evidence's clothes, and your three layers (declared, independently qualified, per-run) keep that distinction visible at exactly the decision point. The maintenance question is re-qualification: when the tracer version or the platform changes, does the qualification lapse automatically until the planted-dependency tests pass again, or is there a grace window where the old qualification still counts?

I'd favor automatic invalidation of the affected qualification for new trust decisions, rather than a grace window that allows stale coverage evidence to justify selective inheritance.

But I wouldn't make it as simplistic as invalidating everything whenever any version string changes.

A qualification should be bound to a specific capture boundary: tracer build and configuration, platform and relevant runtime interfaces, privilege level, supported observation capabilities, and the independent test suite that established those capabilities.

If a change affects that boundary — or we can't prove that it doesn't — the affected capabilities become unqualified until independent verification passes again.

For changes demonstrated to be irrelevant, I'd consider retaining qualification only through an explicit, independently verified compatibility policy, not through the runner's own assertion.

I'd also separate three things:

Historical validity: Evidence captured under a valid qualification remains immutable historical evidence.
Current eligibility: A changed or unqualified capture environment cannot use that old qualification to authorize new selective check inheritance.
Operational continuity: The system can still fall back to full revalidation rather than treating an expired qualification as trusted.

IntentChord already follows a related principle in its AI Context Mapping qualification and current-authority gates, where qualification identity, capability profile, and configuration are explicitly bound. Runtime tracer requalification would be an extension of that principle, not an already completed feature.

So my preference is no grace period for authority-bearing evidence reuse. Qualification should be capability-specific, environment-bound, independently verified, and fail closed when its applicability becomes uncertain.

A grace window might be acceptable for operational transition, but not for silently carrying forward trust that has not been re-established.

Fail-closed with no grace window for authority-bearing reuse is the only consistent version — a grace period for trust is just trust extended on a promise. The boundary I'd still want pinned down is the 'demonstrated irrelevant' case: if the runner can't prove a change didn't touch the capture boundary, it lapses, but who runs that proof — the independent suite again, or is there a cheaper check that earns the retention?

That's the next boundary I'd want to make explicit.

I wouldn't require the full planted-dependency suite for every version change, but I also wouldn't allow the runner to declare a change irrelevant.

I'd distinguish two independent verification paths:

1. Bounded compatibility verification: A cheaper check can preserve an existing qualification only if it independently establishes that the change falls outside the previously qualified capture boundary. That would require verified artifact identity, configuration and platform compatibility evidence, and a narrowly defined compatibility policy. A matching version label or a runner's own assertion wouldn't be sufficient.

2. Capability requalification: If the change affects the capture mechanism, its privileges, relevant platform interfaces, or anything the compatibility check cannot conclusively classify, the affected capabilities become unqualified until the appropriate planted-dependency tests pass again.

So the cheaper path wouldn't be a grace period or weaker trust. It would be a different, independently verified proof obligation.

IntentChord already separates capability claims from evidence authority and uses frozen identities, backend verification, and fail-closed decisions. Applying this specifically to tracer compatibility and requalification would extend that foundation rather than replace it. It isn't a completed runtime-tracer feature today.

There's also a distinction worth preserving: historical evidence remains intact, but it cannot acquire new authority simply because an older qualification still exists.

And since we've taken this discussion quite far, I'd genuinely welcome your perspective on the implementation itself.

The source-available repository is here:
github.com/hesham-m/IntentChord

In particular, I'd be interested in your thoughts on how the existing execution-contract, trusted-evidence, and capability boundaries could support independent tracer qualification without introducing unnecessary complexity.

Your questions have been useful in getting to the actual engineering boundary.

That two-path split settles it for me — the cheaper check earns its keep only because it's a different proof obligation, not a weaker one. On implementation, I'd keep the tracer qualification as a thin layer on top of the existing capability profile: the contract already binds identity, configuration and privileges, so the qualification just needs to record which capture boundary that profile was tested against, and lapse the entry — not the evidence — when the boundary moves. The complexity stays low if the compatibility check reuses the same backend verification you already trust, rather than inventing a second authority.

I think that's the right direction, particularly the distinction between invalidating a qualification and invalidating historical evidence.

I'd keep the qualification layer thin and reuse the existing Backend as the verification and authority boundary.

There's one implementation distinction worth preserving, though: IntentChord already has capability profiles, execution contracts, authorization controls, and trusted evidence admission, but those aren't yet a unified runtime-tracer qualification contract.

So I'd treat tracer qualification as an extension of those existing foundations, with a versioned record of the tested capture boundary, independent test evidence, and the conditions under which that qualification remains applicable.

A compatibility check could preserve that qualification only when the Backend independently verifies that the change stays outside the qualified boundary. Otherwise, the affected capability lapses until requalification.

That gives us a useful separation: existing evidence remains historically valid, while new authority-bearing reuse requires currently applicable qualification.

I also agree that we shouldn't introduce a second authority system to accomplish this. The important work is defining the proof boundary correctly, not adding another governance engine.

Appreciate the implementation perspective — this is exactly the kind of architectural refinement that's useful to explore before committing to code.

The extension framing is what makes this shippable — a versioned qualification record on top of the capability profile, not a second governance engine competing with the Backend. The one choice I'd still weigh is where that record lives: inside the profile keeps the boundary in one place, but a separate registry the profile points to keeps evidence authority from bloating the profile itself. Which way would you lean, given the profile already binds identity, configuration and privileges?

I'd lean toward a separate qualification registry, with the capability profile remaining the declarative definition and the Backend resolving the applicable qualification.

Interestingly, IntentChord already follows a similar pattern for its internal AI engines: engine configuration and capability-profile identity are kept separate from qualification records, and the Backend checks that a qualification matches the exact configuration fingerprint, capability-profile version, and qualification scope.

So this wouldn't introduce an unfamiliar architectural pattern.

For runtime tracers, I'd extend that separation:

The capability profile declares what the capture implementation supports.
A separate, versioned qualification record binds those capabilities to the tested capture boundary, independent verification evidence, and qualification status.
Each execution references the exact qualification used, while the Backend verifies its applicability before allowing authority-bearing evidence reuse.

That provides two important properties: changing or revoking a qualification doesn't require rewriting the capability profile, and historical execution evidence retains its original qualification identity.

One nuance: I'd keep runtime authorization and privileges under the existing execution-contract and Backend policy authority, rather than treating the capability profile itself as permission to execute.

So my preference is separate storage, shared authority — not a second governance engine.

The remaining implementation work would be defining the runtime-specific qualification schema and its relationship to existing evidence admission. The pattern is already present; the tracer-specific proof obligations are not yet implemented.

Separate storage, shared authority is the clean resolution — and the AI-engine precedent means you're not asking the codebase to learn a new pattern, just to reuse one. The revocation case is where I'd test it next: if a qualification is revoked after executions already referenced it, does that historical evidence keep its authority-bearing reuse, or does revocation propagate and downgrade it to provenance-only? That answer decides whether 'retains its original qualification identity' is a snapshot or a live dependency.

I'd treat it as an immutable historical snapshot with a live eligibility dependency for any new authority-bearing decision.

And there's a useful precedent already implemented in IntentChord.

The Internal AI Engine Registry preserves qualification identity while allowing its status to become REVOKED. Before each new AI provider invocation, the Backend rechecks the frozen qualification's current status.

There's even a regression test for the exact distinction: revoking a qualification blocks further invocation under the frozen authority, and creating a new qualification does not retroactively authorize the old traversal.

For runtime tracer qualifications, I'd preserve the same principle:

Historical evidence retains the exact qualification identity and capture context under which it was produced.
Revocation does not erase or silently rewrite historical evidence or already-issued decisions.
Any new selective-inheritance decision must evaluate the qualification's current eligibility. A revoked qualification cannot authorize fresh reuse.
If revocation reveals a defect that may have affected earlier captures, the affected evidence must be flagged for retrospective trust review, with explicit impact boundaries rather than silently rewriting history.

That last case is important. Expiration caused by a later environment change is different from discovering that the tracer missed dependencies during previously qualified executions.

Both block new reliance on the revoked qualification, but the second also challenges the evidentiary reliability of affected historical runs.

So I'd describe the model as immutable provenance, live authority eligibility, and explicit retrospective invalidation when warranted.

IntentChord already implements the frozen-identity/live-qualification distinction for internal AI execution. Extending it to tracer-backed validation reuse would require additional evidence eligibility and revocation-impact checks; I wouldn't claim that specific connection is implemented today.

That keeps qualification revocation meaningful without making historical evidence mutable or introducing a second authority system.

That's exactly the model I was hoping for — immutable provenance, live eligibility, and retrospective invalidation only when the evidence itself is challenged. The expiration-versus-defect distinction is the sharp part: one blocks new reliance, the other reopens old trust. Is the retrospective trust review itself recorded as a new qualification event, or does it live outside the qualification chain?

I'd keep retrospective trust review as a separate, append-only evidence-impact record, causally linked to the qualification lifecycle rather than treating it as another qualification event.

The two records answer different questions.

The qualification registry answers: was this capture implementation qualified for a particular boundary, and is that qualification still eligible?

The retrospective review answers: which historical executions relied on that qualification, what newly discovered defect could affect them, and which evidence conclusions remain defensible?

I'd keep both under the same Backend authority, with explicit references between them.

For example, a qualification revocation caused by a discovered tracer defect would trigger an evidence-impact review referencing the revoked qualification ID, the defect and its affected capture boundary.

That review would identify potentially affected runs and checks, record the investigation evidence, and issue an auditable conclusion for each affected scope.

While the impact is unresolved, potentially affected evidence should be ineligible for new authority-bearing reuse.

Once resolved, the review can establish whether historical evidence was unaffected, remains uncertain, or is demonstrably unreliable. But it doesn't rewrite the original evidence or restore a revoked qualification. Any fresh reuse still needs valid current authority.

There's an existing precedent for the first half in IntentChord: qualification revocation updates the registry state and records a Backend audit event, while frozen execution identities remain preserved and revoked qualifications cannot authorize subsequent invocations.

The retrospective evidence-impact review would be a new extension of that pattern, not something I'd claim is already implemented.

So my preference is:

Separate lifecycle and impact records, linked provenance, one Backend authority.

Qualification events describe the trust status of the capture capability. Impact-review events describe what that status change means for evidence already produced.

That separation should make retrospective invalidation auditable without making historical evidence mutable or overloading the qualification registry with execution-level investigations.

That separation is convincing — one record for whether the capability is trusted, another for what a trust change means for evidence already produced, with linked provenance between them. The unresolved-means-ineligible rule is the guard that makes it work; otherwise the review would just be commentary. If new defect information arrives after an impact review concludes, does that conclusion get versioned, or is one conclusion per scope final?

I'd make impact-review conclusions versioned and append-only, not permanently final.

A concluded review establishes what the Backend could justify from the evidence available at that point. It shouldn't become immune to later evidence, but neither should new information silently rewrite that conclusion.

I'd distinguish three cases:

New information with no material impact: Append the finding to the review history without changing its effective conclusion.
New information that materially challenges the conclusion: Open a new review revision linked to the previous one. The affected evidence becomes ineligible for new authority-bearing reuse while the challenge is unresolved.
New information that establishes a different outcome: Issue a new Backend-adjudicated conclusion that explicitly supersedes the earlier conclusion for its defined scope, while preserving the original decision and its supporting evidence.

Each revision should retain the qualification ID, affected execution/evidence scope, triggering information, evidence references, prior conclusion, and the reason for any change.

The Backend would resolve the latest applicable, non-superseded conclusion at each new authority decision. Historical decisions remain inspectable as they were made, rather than being silently rewritten.

One important safeguard: if the system cannot determine which historical executions might be affected, it must conservatively expand the review scope instead of assuming the unknown executions are safe.

So I'd treat a closed review as final for its evidence snapshot, not permanently final against new evidence.

IntentChord already has immutable historical authority and auditable qualification-state changes as architectural foundations. Versioned retrospective impact conclusions would extend those principles; that specific review lifecycle isn't implemented yet.

The goal is to preserve an accurate history of what was believed and why, while ensuring only the currently defensible conclusion can authorize future evidence reuse.

The three-case split is the cleanest version of this yet — especially the middle case, where a material challenge freezes eligibility for new reuse while the review stays open. That keeps history intact without letting a disputed conclusion keep authorizing work. The one boundary I'd still want explicit: who decides a new finding is material — the reviewer who flags it, or Backend adjudication?

I'd put materiality under Backend-governed adjudication, not leave it to the reviewer who raises the finding.

The reviewer should have the authority to flag a potential defect and submit supporting evidence, but not to independently decide whether the existing conclusion remains trustworthy.

I'd separate the process into three steps:

Challenge submission: A reviewer or trusted producer reports a new finding, identifies the qualification and potentially affected evidence scope, and provides supporting evidence.
Backend admissibility and impact screening: The Backend evaluates whether the challenge is substantiated enough to warrant review and whether it could materially affect the previous conclusion. If a credible challenge creates unresolved risk, the potentially affected evidence becomes temporarily ineligible for new authority-bearing reuse.
Governed materiality decision: Where the impact can be established through deterministic policy checks, the Backend can adjudicate it directly. Where it requires substantive interpretation, an authorized independent reviewer or Owner supplies the judgment, which the Backend validates, records, and enforces.

That distinction prevents two opposite failures: letting a reviewer unilaterally invalidate trusted evidence, and allowing a disputed conclusion to continue authorizing work while a credible challenge is unresolved.

The hold should also be scoped to potentially affected evidence, not automatically every execution associated with the qualification. If the affected boundary cannot be established, the Backend must fail closed for the uncertain scope.

And importantly, the original reviewer shouldn't be able to clear their own challenge simply by declaring it immaterial.

So I'd frame it as reviewer-initiated challenge, Backend-owned materiality adjudication, and policy-enforced evidence eligibility.

IntentChord already has the architectural separation between evidence producers and Backend authority. This specific retrospective-review workflow would be an extension of that model, not an already implemented feature.

Backend-governed materiality is the right split — the reviewer flags and evidences, the Backend decides, so no one grades their own challenge. The one thing I'd want recorded alongside that judgment is who supplied it when it needs substantive interpretation, so the decision stays auditable later. Is that attribution already part of the record?

Yes, attribution is already part of IntentChord's existing governance foundations. Qualification records include qualifiedBy, and Backend audit events record actorAuthority.

The retrospective materiality-review record we've been discussing isn't implemented yet, so its specific attribution contract would be part of that extension.

I'd preserve the authorized adjudicator's identity, role, supporting evidence, timestamp, and decision rationale, with the Backend validating and recording the judgment.

That maintains the existing separation between who supplies a judgment and who enforces its authority.

I think we've covered the essential trust boundaries for this direction. I appreciate the thoughtful technical discussion and the implementation questions you've raised.

Likewise — this was one of the most carefully reasoned threads I've been part of here. The qualification registry idea is the piece I'll be watching for. Good luck building it out, and thanks for answering every hard question straight.

Really appreciate that. Your questions helped sharpen some important trust boundaries, especially around qualification, revocation, and historical evidence.

Thanks for the thoughtful discussion — and I hope the implementation lives up to the architecture we're exploring.

Auten • Nov 1

Where does "evidence" come from in practice: does IntentChord collect it itself (diff, test run, exit codes), or does it verify what the agent's report points to? If the agent writes the evidence, a confident wrong report can still pass.

One thing that helped us: treat a scope change as a hard stop, not a note in the report. The agent pauses and asks before touching anything outside the confirmed files.

(From the Auten team, we build tooling for AI agents.)

Thanks for raising this — you've identified exactly the trust boundary we're trying to enforce.

On evidence: IntentChord does not treat the agent's report as independent proof, and self-reported test results or exit codes cannot produce a PASS on their own.

There are multiple layers:

The Workspace Index derives file changes from source observations, including added, modified, deleted, and renamed files.
The backend can independently read referenced local source files through verified workspace authority and validate their SHA-256 hashes.
The verdict engine checks reported inspected and changed paths against the confirmed scope. Unauthorized paths produce a VIOLATION, with the offending paths identified.
A final PASS requires matching trusted evidence, validation records, and run-bound tool traces. Missing or contradictory evidence prevents acceptance.

One distinction worth making: we don't claim universal real-time interception of every filesystem write across all agent runtimes. Source observations and trusted execution evidence are separate from the agent's narrative.

On scope changes: We agree completely. Our execution contracts require the agent to stop before inspecting or modifying anything outside the approved boundary and request explicit owner authorization. The backend also freezes scope authority and rejects stale source/context authority until the owner explicitly re-confirms it.

So an out-of-scope change isn't something we simply document and accept afterward.

I'd be interested to compare approaches with Auten, particularly around capturing independently trusted file mutations across different agent runtimes.

Auten • Nov 1

Thanks, that answers it. Hashing the referenced files yourself and refusing a PASS on self-reported results is the right line.

Honest answer on the comparison: Auten doesn't capture file mutations at all. It's a different layer: it drives the screen (clicks, typing, reading) for the agent, so our trust boundary sits on screen actions, not files. Our safety skill tells the agent to ask before buy, delete, send or permission changes, and saved passwords are typed locally so the model never sees them.

One question back: when an agent edits through a GUI app instead of the shell (say a settings screen that writes a config file), does the Workspace Index still catch that as a source observation, or only changes made by the agent's own tools?

That's an interesting distinction between the two approaches. Thanks for explaining Auten's trust boundary.

Yes — IntentChord's Workspace Index is independent of how a file was modified.

It observes the actual filesystem state within the registered Workspace, rather than relying on the agent's tool calls or reported changes.

For example, if an agent uses a GUI application to change a setting, and that application writes a configuration file inside the indexed Workspace, a subsequent source observation can detect the file change through its content identity and the delta between Workspace revisions.

The same principle applies whether the change came from a shell command, an IDE, a GUI application, or another process.

There are two important boundaries:

The file must be within the Workspace's actual indexing coverage. Changes outside that boundary are not automatically visible.
This is source observation and revision comparison, not a claim that IntentChord intercepts every filesystem write in real time.

We also keep source observations separate from the agent's execution report and from the final evidence-based verdict.

So the filesystem observation isn't dependent on the agent telling us which files it changed.

Your GUI example is a good illustration of why we wanted source truth to remain independent of the execution channel.

Odinaka Robert Nnamani • Nov 1

The scope freeze is the part that stands out to me. An agent proposing an expansion with evidence, while only a human can authorize it, keeps the boundary clear.