Skip to content
🧭
Atticus detail route

Governance Policies

Use this page when the real question is where the Atticus boundary sits: what agents can do locally, what should pause for a ruling, and what Atlas deliberately leaves out.
Validated · Oct 6, 2026The Atticus proof still matches the governance-first district contract, the Atticus boundary split, and the phone-first Decision / Handoff / Trust exits that keep adjacent ruling and trust pages visible before the rulebook sections begin.
Boundary first

Answer the boundary question before anything else

The shortest useful answer is whether the work stays local, needs a ruling, or is mis-owned. Start there, then read the deeper rules only if you still need them.

Use the trust and ownership split

The policy layer should keep routine work moving while making real approval-sensitive changes obvious. This is the quick answer most readers came for.
Question
The work stays inside the current project lane and does not move trust, spend, or public exposure.
Start with
Treat it as local execution.
Why
Atticus is not meant to re-approve routine work that already belongs to the owning agent or charter.
Examples: code changes inside scope, focused documentation cleanup, and bounded test or tooling improvements.
Question
The work changes authority, risk, or who the system affects.
Start with
Treat it as approval-sensitive.
Why
This is where the governance gate is doing real work: slowing the path down before a scope jump becomes an implementation fact.
Examples: public publishing, infrastructure changes, new recurring automation, or actions that shift what another agent can do.
Question
The request asks Atticus to own another team’s domain directly.
Start with
Expect a boundary correction.
Why
Atticus protects alignment and shared knowledge health, but domain ownership stays with the lane that builds, operates, or publishes the artifact.
Atlas should help readers find the right owner instead of implying Atticus becomes the operator.
Core rules

The policies that keep autonomy aligned

These rules are durable because they explain why Atticus exists, not because they list every current operational detail.
Keep alignment rules external to the worker

Atticus exists so policy can evolve without hardcoding every rule into every prompt, route, or agent lane.

This is why governance still matters even when a worker is technically capable of acting on its own.
Prefer observation before assertion

Atticus should read evidence, separate what is known from what is inferred, and only then classify or publish a conclusion.

That posture keeps the gate trustworthy for both governance and knowledge-maintenance work.
Protect ownership boundaries

Atticus can challenge scope, redirect the path, or keep the record straight, but it does not silently absorb delivery ownership from another agent or charter.

Network stewardship is not a shortcut to “Atticus owns everything.”
Escalate real authority changes to humans

Policy-sensitive changes that move trust, exposure, or responsibility should surface a human approval point rather than rely on optimistic local interpretation.

The rule is about authority, not about making every change feel heavy.
Policy evolution

Policies change through human authority, not silent drift

Atticus can surface patterns and preserve the audit trail, but it is not a self-editing sovereign. Human approval remains the place where the policy itself changes.

Continue through the Atticus cluster

Decision Framework

See how Atticus turns these boundaries into concrete ruling shapes for live work.

Open Decision Framework
Integration Guide

Read the lighter handoff explanation once the policy boundary is clear.

Open Integration Guide
Architecture

Zoom out to the system-wide trust model that makes the Atticus boundary necessary.

Open Architecture