How are intents signed?

The shim authenticates to the master with a developer's SSH key, and agent IDs are scoped under that identity with a UUID. Spoofing an intent requires the private key, the same trust model as `git push`.

Does the audit trail store my source code?

No. The conflict log keeps permanent metadata: the concepts that conflicted, the agents involved, and the resolution. Source-level diffs used for soft-conflict detection are retained only for a fixed window and then discarded.

Is Tetherlab a compliance certification?

No. Tetherlab produces signed, replayable provenance and a causal record of every change. Mapping that evidence to a framework such as SOC 2 is work your compliance process owns.

Use case

Audit-grade by construction

Branching audit tree of intents rooted at a single signed origin

By Tetherlab team

Updated 2026-05-29

Overview

When agents write most of the code, who decided this and why stops being a nice-to-have. Audit-grade by construction means the answer is a property of how the system works, not a report you assemble after the fact.

Signed intents end-to-end

Every intent is signed. The shim authenticates to the master with a developer's SSH key, and agent IDs are scoped under that identity. Spoofing an intent requires the private key, the same trust model as git push.

Because the submitter is the shim and the identity is cryptographic, the provenance of a change is established at the moment the plan is declared, before any code exists.

The verdict trail

Every coordination event is appended to a log: intent submission, concept match, conflict detection, verdict, plan completion. The log is the source of truth; the dashboard's history and conflict views are projections of it.

When a semantic branch closes, the master writes a structured merge record with the causal chain instead of dumping cryptic commits into main.

merge record

Semantic branch closed: "JWT auth migration"
  Modified concepts: session store contract, auth contract
  Downstream effects resolved:
    - Carol's route handlers updated token extraction (conflict_003)
  Causal chain: intent_alice_001 → conflict_003 → intent_carol_002 → resolved

Exporting the chain

The conflict log retains permanent metadata: which concepts conflicted, which agents were involved, and the resolution applied. It does this without storing source-level diffs, which are kept only for a fixed window and then discarded.

The result is a durable record of intent and resolution that stays useful for the master's future matching decisions without becoming a growing code-leak liability.

Mapping to common compliance frameworks

A signed, replayable chain of who intended what, what conflicted, and how it resolved is the raw material most change-management and audit requirements ask for. The intent timeline gives reviewers a causal narrative rather than 47 cryptic commit messages.

Scope note

Tetherlab produces the signed provenance and the causal record. Mapping that to a specific framework like SOC 2 or ISO 27001 is work your compliance process owns; Tetherlab supplies the evidence, not the certification.

Next steps

The same timeline powers plan-stage incident response. For the identity model behind signing, see cross-machine coordination.

Frequently asked questions

How are intents signed?: The shim authenticates to the master with a developer's SSH key, and agent IDs are scoped under that identity with a UUID. Spoofing an intent requires the private key, the same trust model as git push.
Does the audit trail store my source code?: No. The conflict log keeps permanent metadata: the concepts that conflicted, the agents involved, and the resolution. Source-level diffs used for soft-conflict detection are retained only for a fixed window and then discarded.
Is Tetherlab a compliance certification?: No. Tetherlab produces signed, replayable provenance and a causal record of every change. Mapping that evidence to a framework such as SOC 2 is work your compliance process owns.