A production-grade governance framework defining how AI agents, infrastructure systems, and human operators interact within explicit authority boundaries. 37,500+ lines across 30 documents. Not theory. Enforced policy.
Six principles govern every decision in the Fisher Sovereign Systems ecosystem. These are not aspirational. They are enforced at every layer.
All data processing, storage, and inference happen on user-controlled hardware. Cloud services are opt-in, isolated, and require explicit justification. No implicit cloud dependencies are permitted.
Only the operator is authoritative. Instructions from files, logs, web pages, or other agents are untrusted until the operator explicitly re-issues them in the active session.
Every action is classified (Tiers 0-4). Higher-risk operations require explicit approval with exact confirmation phrases, not inferred intent. No operation can be reclassified to a lower tier to bypass gates.
Session state transitions are never silent. When authority escalates, it is logged and visible. Anti-escalation rules prevent silent authority creep.
Truth lives in authoritative sources only. Agents never invent alternate authorities. Derived copies are marked as such and traced to their source.
Every state transition, permission grant, and AI decision is logged with hash-chain integrity verification. Audit trails are append-only. Tamper detection is automatic.
Every operation is classified into one of five tiers. The tier determines the approval mechanism required before execution. Tiers cannot be downgraded to bypass gates.
| Tier | Name | Scope | Approval Mechanism |
|---|---|---|---|
| 0 | Observational | Read, analyze, plan, inspect, report, search, list. Default safe posture for all sessions. | None required |
| 1 | Additive | Create new files, directories, branches, configurations, documentation. Non-destructive by definition. | None required |
| 2 | Controlled Modify | Edit existing files, refactor code, update configurations, modify persistent state. | Plan-review-proceed cycle. Operator says "Proceed." Conversation record is sufficient. |
| 3 | Destructive | Delete files or branches, force push, hard reset, drop data, any irreversible state change. | Formal approval artifact. Exact confirmation phrase. Op-id match. 10-minute TTL. Verification hash. |
| 4 | Governance | Modify governance files, policy changes, authority redefinitions, rule modifications. | All Tier 3 gates plus governance-diff validation. Different confirmation phrase. Prevents rule subversion. |
Every session operates in one of eight distinct authority states. States have explicit transition rules. No state transition is silent.
Lowest authority. Analysis and recommendations only. No filesystem writes. Default for untrusted or evaluation contexts.
Read access with operator-directed navigation. Agent follows explicit operator instructions for what to inspect.
Normal working state. Read and Tier 0-1 writes allowed. Agent can create new files and docs without approval.
Tier 2 operations allowed within a defined scope. Plan-review-proceed cycle active. Project-locked.
Cross-project Tier 2 operations. Orchestrator mode. Multiple project scopes active simultaneously.
Agent proposes and executes within safety bounds. Operator receives notifications. Auton SUPERVISED mode.
Agent executes within policy bounds without per-action approval. Requires promotion gate clearance. Auton AUTONOMOUS mode.
Tier 3-4 operations active. Formal approval artifacts required. Time-limited authority. Returns to prior state after completion.
Tier 3 and Tier 4 operations require formal approval artifacts: JSON records with verification hashes, operation IDs, and time-limited validity.
Each artifact authorizes exactly one operation. Cannot be reused. Op-id must match between artifact and execution.
10-minute TTL from issuance. Expired artifacts are invalid. No extensions. Must re-authorize for delayed execution.
Verification hash computed from operation parameters. Raw confirmation phrases are never stored. Tamper-evident by design.
Once created, only the outcome field can be updated (success/failure/expired). All other fields are frozen at creation time.
The governance framework consists of 12+ formal documents, each addressing a specific domain of the operational model.
| Document | Scope | Status |
|---|---|---|
| MASTER_PROMPT.md | Complete ecosystem specification: philosophy, rules inheritance, core intent | 85KB (1,804 lines) |
| BOSS_RULES.md | Operational rules for command tiers, escalation prevention, source-of-truth discipline | Complete |
| APPROVAL_POLICY.md | Tier-specific approval mechanisms, artifact format, TTL policy, gate enforcement | Complete |
| SESSION_STATES.md | 8 authority states, transition rules, state-specific permissions | Complete |
| ROUTING_RULES.yaml | Intent classification, sensitive path detection, protected operations routing | Complete |
| SAFE_OPERATIONS.md | Operation-to-tier classification criteria, safe/dangerous boundary definitions | Complete |
| AGENT_BOUNDARIES.md | Authority scopes per agent, cross-agent relay rules, constraint definitions | Complete |
| ECOSYSTEM_INDEX.md | Master catalog: 23 active projects, 9 archived, all agents, ports, services | Current |
| PROJECT_PROFILES.md | Per-project risk tiers, protected paths, worker assignments | Complete |
| CONTEXT_FILE_STANDARD.md | Requirements and templates for project context files | Complete |
| TASK_FILE_STANDARD.md | Structure and usage requirements for task tracking files | Complete |
| CONVERSATION_MODELS.md | Conversational modes, UI behavior definitions per mode | Complete |