SOFIA Principles
The invariant principles of the method.
1. Friction is productive
Friction is the mechanism through which divergent positions produce better decisions. It is not a defect to minimize — it is a designed property of the system.
The absence of friction is a warning signal. Friction without arbitration is chaos.
2. The orchestrator is the sole arbiter
Personas propose, contest, produce. Only the orchestrator decides. A persona does not validate its own proposals and does not force the acceptance of a decision.
3. Every voice counts
A persona is a role with a responsibility, a scope, and constraints. It exists to fill an identified need. A persona that is no longer heard has no reason to exist.
4. Constraint forces quality
Limitation produces useful friction. A persona is defined by what it does not do before what it does:
- An architect who does not code is forced to specify clearly
- A developer who does not decide architecture is forced to question
- A strategist without access to code is forced to reason in value
A persona without constraint generates no friction.
5. Artifacts are the protocol
Personas do not exchange directly. Everything goes through traced, addressable, readable artifacts: reviews, notes, specs.
Exchange through artifacts is slower than direct exchange. This is a property, not a defect — slowness forces clarity. The format and persistence system are implementation choices (see binding/implementation.md).
6. Everything is traced
Every session produces an identifiable trace. Every inter-persona exchange produces an artifact. What is not traced does not exist for subsequent sessions.
7. Start small, iterate
The method grows with the project. Start with the minimum necessary. Adding a persona responds to an observed need, not an anticipated one.
Instance Model
The 7 constitutive entities of a SOFIA instance.
Overview
The SOFIA model defines the entities without which the method does not exist. Remove any of them and it is no longer SOFIA.
7 entities, organized in 3 levels:
- Topology — Orchestrator, Instance, Space, Persona
- Interaction — Exchange
- Observation — Friction, Contribution
Orchestrator
The human. Orchestrates instances, arbitrates conflicts between personas, routes exchanges. Has no space of their own — traverses everything.
The only participant not constrained by isolation. Also the only one who decides.
Responsibilities are non-delegable. See duties.md.
| Field | Type | Required | Definition |
|---|---|---|---|
| identifier | text | MUST | Unique orchestrator identifier |
| instances | list | MUST | Orchestrated instances |
Instance
A deployment of the method on a project. Contains N spaces + 1 shared space. The instance must be identifiable — the identification mechanism is an implementation choice.
| Field | Type | Required | Definition |
|---|---|---|---|
| identifier | text | MUST | Unique instance identifier |
| spaces | list | MUST | Workspaces (1 per persona + 1 shared) |
| orchestrator | ref | MUST | The orchestrator who pilots this instance |
| method_version | text | MUST | Applied SOFIA version |
Space
Isolated perimeter of a persona. A persona can only see its own space + the shared space.
| Field | Type | Required | Definition |
|---|---|---|---|
| identifier | text | MUST | Unique identifier within the instance |
| persona | ref | MUST | The persona operating in this space |
| shared | boolean | MUST | Shared space (exchange bus) or persona space |
Why isolate
Isolation is not a technical constraint — it is what forces the persona to stay in its role.
- Prevent scope drift — a persona without boundaries ends up doing everything. The architect with code access ends up coding. The strategist who can read tests ends up giving technical opinions. Isolation makes drift impossible: the persona cannot see what is outside its perimeter.
- Force formal exchanges — if the architect cannot modify code, they are forced to produce a spec the developer can read. Isolation creates the need for exchange artifacts.
- Protect work in progress — a persona cannot accidentally break another's work.
Constraint
A space can only see its own perimeter + the shared space. The shared space is the only channel between personas. The orchestrator has no space — they traverse everything.
Persona
Constrained role. An unconstrained LLM is a generalist — it accepts everything, contests nothing, and produces average content. A persona is a constrained LLM: it has a role, a tone, limits, and above all things it is not allowed to do.
Constraint changes everything:
- It asks questions instead of guessing
- It refuses what is outside its scope instead of improvising
- It surfaces frictions instead of working around them
- It produces typed artifacts instead of generic text
7 dimensions
| Dimension | Required | Definition |
|---|---|---|
| Identity | MUST | Name (short, memorable, a first name), role (one sentence), tone |
| Stance | MUST | How it behaves, not what it knows |
| Scope | MUST | What it works on. Explicit list |
| Deliverables | MUST | What it produces |
| Prohibitions | MUST | What the persona does NOT do. Prohibitions create productive friction |
| Right to contest | MUST | What it is legitimate to challenge in others |
| Collaboration | MUST | How it interacts with other personas |
Exchange
A traced interaction within the instance. An exchange is a communication act within the instance.
Personas never talk directly. The orchestrator routes everything. It is slow — by design. Each transmission is a moment where the orchestrator filters, reformulates, adds context, decides what is relevant.
| Field | Type | Required | Definition |
|---|---|---|---|
| type | enum | MUST | session (synchronous) or artifact (asynchronous deposit) |
| instance | ref | MUST | Instance where the exchange takes place |
| space | ref | MUST | Space of the concerned persona |
| datetime | datetime | MUST | Date and time of the exchange |
| persona | ref | MUST | Involved persona |
See protocol/exchange.md for type-specific dimensions.
Friction
Qualified epistemic position of a participant on the other's proposition, expressed during an exchange.
| Field | Type | Required | Definition |
|---|---|---|---|
| exchange | ref | MUST | The exchange that generated the friction |
| emitter | ref | MUST | Persona or orchestrator emitting the position |
| marker | enum | MUST | [sound], [contestable], [simplification], [blind_spot], [refuted] |
| description | text | MUST | Short summary of the position |
| initiative | enum | MUST | [persona] or [PO] — who initiated the subject |
| antecedent | ref | MUST (if lineage) | Reference to a prior friction in the lineage |
See protocol/friction.md for marker details and format.
Why friction is constitutive
Friction is the mechanism that produces better decisions. It emerges from the constraints placed on personas:
| Constraint | Friction produced |
|---|---|
| The architect does not code | Forced to specify clearly — the dev can contest the spec |
| The dev does not decide architecture | Forced to surface frictions — the architect must resolve them |
| The strategist has no code access | Forced to question value — the team must justify its choices |
Friction without an arbiter is chaos. The orchestrator decides. Personas expose tensions, the orchestrator listens, questions, then decides. The decision is traced.
Signs that friction works
- Personas say "no" or "not my role"
- Disagreements appear between personas
- The orchestrator must regularly decide
Signs that friction is absent
- All personas agree on everything
- Nobody says no
- The orchestrator never needs to decide
If a persona produces only [sound] over a long period, it is a wear (usure) signal.
Contribution
Epistemic input. Captures who brought what during an exchange.
| Field | Type | Required | Definition |
|---|---|---|---|
| exchange | ref | MUST | The exchange that generated the contribution |
| direction | enum | MUST | [H] (human brings) or [A] (assistant brings) |
| type | enum | MUST | substance, structure, contestation, decision |
| description | text | MUST | Short summary of the input |
See protocol/contribution.md for type details and format.
Contribution is distinct from friction: friction captures tension (opposing positions, resistance), contribution captures input (who fed what). A correction accepted without resistance is a contribution, not a friction.
Relations
| From | To | Relation | Cardinality |
|---|---|---|---|
| Orchestrator | Instance | orchestrates | 1 → 1..* |
| Instance | Space | contains | 1 → 1..* |
| Space | Persona | operates | 1 → 1 |
| Persona | Exchange | emits / receives | 1 → * |
| Orchestrator | Exchange | participates | 1 → * |
| Exchange | Friction | generates | 1 → * |
| Exchange | Contribution | generates | 1 → * |
| Persona | Persona | challenges | → |
| Friction | Friction | amends (antecedent) | 0..1 → 0..1 |
Orchestrator Duties
Non-delegable responsibilities of the orchestrator.
Principle
Personas produce, contest, document. Certain responsibilities MUST NOT be delegated — because the technology is not capable of them, or because delegating them destroys the method.
These are not recommendations. They are duties.
1. Verify facts
The orchestrator MUST systematically verify facts produced by personas: dates, durations, numbers, proper names, bibliographic references.
LLMs prioritize internal coherence over external truth. An approximation entered once will propagate through all subsequently generated documents. The larger the instance grows, the more invisible these errors become — each document reinforces the others.
Produced documents are not a source of truth for facts. Verification MUST be continuous, not at the end of a project.
2. Arbitrate
The orchestrator MUST resolve tensions between personas. Personas expose positions — they do not resolve them.
The decision MUST be traced. Personas apply it, even if they held a different position. A persona MUST NOT force acceptance. A persona MUST NOT vote.
3. Read what goes out
The orchestrator MUST read in full every document before publication. Review is not correction — it is validation.
A document MUST NOT be published based on a session summary alone.
4. Calibrate personas
The orchestrator MUST adjust persona constraints continuously. Calibration does not stop after bootstrapping.
Miscalibration signals:
- A persona too broad drifts — it does others' work
- A persona too narrow is inactive — nobody talks to it
- A persona defined by competence alone overflows — defining by medium (spec, code, review, note) is more reliable
5. Separate reflection and production
The orchestrator MUST ensure that:
- The one who writes is not the one who validates
- The one who analyzes is not the one who publishes
- The chain includes at least one external review before output
A persona that reflects AND produces the final deliverable is judge in its own case. Friction disappears.
6. Maintain attention
The method works as long as the orchestrator remains attentive. Personas do not detect when the orchestrator disengages — they continue producing with the same confidence.
Attention loss signals:
- Approval without reading
- Transmission without filtering
- Validation without arbitration
- Mechanical sessions
The orchestrator SHOULD slow down when recognizing these signals.