Skip to content
🧭
Atticus detail route

Integration Guide

Use this page when you already understand Atticus as a governance surface and now need the shortest explanation of when it enters the loop, what good input looks like, and what changes after the ruling.
Validated Β· Oct 6, 2026The 2026-09-29 pass re-ran the charter-family census across the Atticus cluster and converged this page's lens reminder onto the five-charter family the registry mirror carries. The proof still matches the governance-first district contract, the current Atticus handoff model, and the phone-first Decision / Policies / Coordination exits that keep adjacent governance answers visible above the fold.
When Atticus enters

Decide whether governance belongs in the loop

Most readers do not need a procedural tutorial. They need the shortest path to deciding whether Atticus belongs in the loop at all, and what threshold makes that true.

Use the governance handoff only when it changes the path

The integration point should make the next move clearer. If the work is routine and local, Atlas should keep you moving instead of adding a fake gate.
Question
The work is a routine improvement inside an existing project lane.
Start with
Proceed locally.
Why
Atticus does not need to sit inside every normal implementation loop. The governance gate matters when the change moves trust, authority, or exposure.
Examples: bug fixes, copy cleanup, test coverage, and narrow refactors that do not change public or cross-agent boundaries.
Question
The work adds scope, affects policy, or changes who is exposed to the result.
Start with
Bring Atticus into the loop.
Why
The integration point exists to clarify the boundary before a scope jump becomes an implementation commitment.
Examples: new public surfaces, infrastructure changes, approval-sensitive publishing, or cross-lane authority moves.
Question
The work is blocked because ownership or policy is ambiguous.
Start with
Use Atticus to narrow the path.
Why
A good governance handoff should reduce ambiguity, not just delay the work. The useful output is a clearer next move, even if that move belongs to another owner.
Think routing and clarification, not just approval.
Good input

What makes a governance handoff legible

The handoff does not need command syntax. It needs a clear change statement, the uncertain boundary, and the evidence shape that lets Atticus distinguish observation from assumption.
State the proposed change in one sentence

Name the actual move, not a vague desire for approval. Atticus can only classify a real change.

Good shape: what changes, where it lands, and why this is the right moment.
Name the boundary that feels uncertain

Call out whether the risk is scope, public exposure, authority, cost, or another lane’s ownership.

This gives Atticus the policy question instead of forcing it to infer the whole concern.
Include the evidence you already have

A governance handoff is stronger when it starts from observed facts instead of from pure intention.

Atlas stays educational here: the important part is the evidence shape, not the exact runtime command that gathered it.
Ask for the next move, not just a blessing

The most useful Atticus result is usually a clarified path: proceed, escalate, narrow scope, or reroute the owner.

This keeps the handoff outcome practical without turning the page into an API surface.
After review

A ruling changes the next move, not the owner

Atticus can keep work local, require a stronger approval path, or reroute the owner. What it should not do is quietly absorb delivery ownership from the team that still has to ship the artifact.

Continue through the Atticus cluster

Decision Framework

See what the governance outcomes mean once Atticus is already in the loop.

Open Decision Framework
Governance Policies

Read the boundary that determines when this handoff should happen in the first place.

Open Governance Policies
Coordination Patterns

Zoom back out to the broader multi-agent handoff model after the Atticus-specific gate is clear.

Open Coordination Patterns