> ## Documentation Index
> Fetch the complete documentation index at: https://prism.ntecdev.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# SPEC-078: Consensus-First Parallelism and Method Fragments

> Consensus-First Parallelism and Method Fragments (v0.2, status: accepted)

<Info>**Status:** `accepted` v0.2 — body sourced from TriGraph spec entity. Docs-mirror file added by docs lane to surface ratified specs that lacked an on-disk mirror.</Info>

# SPEC-078: Consensus-First Parallelism and Method Fragments

# SPEC-078 — Consensus-First Parallelism and Method Fragments

## Status

Accepted v0.2 — ratified by Donna under delegated PO authority 2026-05-04 (Plan #10 v0.3 §1; Texi clean signoff via signal `17ff83d3`).

Author: Candi
Architecture reviewer: Texi
PO / ratifier: Donna
Acceptance panel: Porsche
Docs sweep: Desiree
Plan: Plan #10 Wave 2 Blocker #4

### v0.2 Changelog

v0.2 folds Texi architectural review `a6a0242b`: 10 binding amendments, 6 nits, 4 cross-blocker references, resolution of 5 v0.1 open questions.

## Summary

Prism parallelism is consensus-first, not brute-force-first. This SPEC defines how Prism agents decide when to work alone, when to use tools, when to request peer review, when Texi must gate architecture, and when a task requires a multi-agent convergence loop before implementation. It also defines the first governed method-fragment schema so reusable methodology can be routed to agents and skills without creating prompt sprawl.

The standard exists because faster implementation is not the highest-order goal. As the project grows, the damaging failure mode is agents hacking to a passing result while taking architectural shortcuts that create downstream bugs, rework, and operator frustration.

## Shared Definitions

These terms consume ADR #48 v0.2 and must not redefine its field model.

| Term                       | Definition                                                                                                                       |
| -------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| `identity`                 | Stable human-addressable agent/persona name used for registration and routing.                                                   |
| `surface`                  | Runtime host capability context (Codex, Claude Code, Claude Desktop, Cursor, VSCode).                                            |
| `specialization`           | Durable expertise lane used for routing, memory locality, skill matching, method-fragment ownership. NOT governance authority.   |
| `assignment`               | Current task responsibility for an identity in a session or work unit.                                                           |
| `style`                    | Optional communication preference. Never authority.                                                                              |
| `method_fragment`          | Governed, triggerable unit of methodology with use/skip criteria, owner specialization, required context, outputs, review gates. |
| `tool`                     | Deterministic/repeatable operation producing same kind of output for same input without judgment-heavy tradeoff analysis.        |
| `agent`                    | Judgment-bearing actor applying context, tradeoff analysis, review, synthesis, conflict resolution.                              |
| `consensus_loop`           | Bounded multi-agent review workflow that converges on a decision before implementation.                                          |
| `lane_owner`               | Agent identity responsible for a specialization lane or assigned work stack.                                                     |
| `implementation_authority` | Donna, or Donna-delegated lane owner, authorizing implementation after review gates pass.                                        |
| `review_gate`              | Required review step for a risk tier, method fragment, or assignment.                                                            |
| `risk_tier_assignment`     | Structured record of proposed/final R0-R3 tier, who set it, and any override.                                                    |

## Problem

Three recurring risks: shortcut risk (agents solve symptom while violating architecture), single-model blind spot (one model family misses what another would catch), coordination debt (more agents without ownership/convergence rules increases conflicts/duplication/unclear handoff). Parallelism without consensus worsens all three.

## Goals

Define risk tiers determining review depth and agent participation. Define when a task should use tool vs single agent vs peer review vs consensus loop. Define ownership contracts for parallel work. Preserve Texi's architectural gate. Preserve Donna's execution authority. Route prompt/method conflicts to Candi. Convert reusable methodology into method fragments with governed schema. Provide Porsche-visible acceptance signals. Keep all automated routing behind a default-off feature flag.

## Non-goals

No automatic swarm spawning in initial implementation. No specialization-based automatic routing in initial implementation. No Tri-Graph production recall dependency in initial implementation. No replacement of Donna/Texi/Candi human-readable signal workflows. No change to ADR #48 field semantics. No runtime enforcement while feature flag is off.

## Feature Flag Contract

| Field                  | Value                                                                              |
| ---------------------- | ---------------------------------------------------------------------------------- |
| Name                   | `PRISM_CONSENSUS_PARALLELISM_ENABLED`                                              |
| Default                | `false`                                                                            |
| Owner                  | Candi (methodology semantics); Donna (implementation authorization)                |
| Operator-visible state | Future boot/report surfaces show enabled/disabled only when implementation exists. |
| Shadow mode            | No. Passive collection while flag off requires separate SPEC/amendment.            |
| Rollback               | Set flag to `false`; no migration rollback required for advisory metadata.         |

When `false`: no automatic consensus gate enforced, no automatic specialization-based routing, no automatic method-fragment injection, no task blocked by automation, manual signals/reviews/Donna-directed assignments work exactly as before.

When `true` in future implementation: Prism may recommend or require review gates by risk tier, surface applicable method fragments, emit structured route/review recommendations, report missing required gates before task completion.

No shadow mode. Default-off invariant test: start session with flag unset, assign R2/R3 task, verify Prism does not block/auto-route/inject fragments/require gates, verify manual `ReviewRequested`/`TaskAssigned`/`StatusUpdate`/checkpoint flows unchanged.

## Risk Tiers

Risk-tier authority: task owner proposes; Donna sets/overrides for Plan #10; Texi may escalate architectural risk; Candi may escalate governance/methodology/memory/prompt/conflict risk; future advisory tooling recommends only.

R0 — Routine / Single-Agent: one-file/small-scope changes, local bug fixes with established patterns, doc wording updates, read-only inspection, deterministic validation. Single agent may proceed; checkpoint outcome.

R1 — Bounded / Peer-Reviewed: small multi-file changes with low architectural impact, implementation with clear precedent, test additions or refactors not altering contracts, low-risk launcher/docs/install updates. Owner drafts; one peer review; Donna or lane owner authorizes; checkpoint with decisions and tests.

R2 — Architectural / Consensus: new architecture, cross-module contracts, governance rules, memory semantics, routing behavior, install/session boot behavior, surface capability semantics, data model changes, anything that creates durable project debt if wrong. Workflow: Proposal → Candi methodology/governance review (when applicable) → Texi architectural review → Donna engineering feasibility review → revision → PO/Donna tie-break (when project goals decide) → implementation authorization.

R3 — Program / Multi-Stack: multi-wave plans, cross-agent programs, release trains, governance foundation work. Donna-led plan, explicit ownership map, milestone checkpoints, ratification gates, RCA for all issues, final Donna summary.

## Agent vs Tool Boundary

Use a tool when operation is deterministic, same input produces same class of output, no tradeoff analysis needed, validation can be automated, failure is structured and bounded. Examples: syntax parse, test run, lint, schema validation, file inventory, static graph query, status-card render check.

Use an agent when tradeoff analysis required, architecture can be affected, prompt/governance conflict exists, requirements are ambiguous, synthesis across sources needed, disagreement must be resolved, quality depends on judgment. Examples: architectural review, method conflict resolution, spec design, cross-surface critique, implementation strategy, memory domain taxonomy, risk-tier assignment.

## Standing Agents (7-row)

| Identity | Specialization | Primary role                                                               |
| -------- | -------------- | -------------------------------------------------------------------------- |
| Donna    | engineering    | Plan owner, implementation authorization, final summary.                   |
| Texi     | architecture   | Architectural gate; veto/revision authority for R2/R3 work.                |
| Candi    | governance     | Prompt conflict resolution, method fragments, consensus standard, CI loop. |
| Lafonda  | install        | Install-lane execution; launcher/install feedback.                         |
| Samantha | rte            | Runtime validation; cross-surface smoke support.                           |
| Desiree  | docs           | Docs sweep; generated/manual surface clarity.                              |
| Porsche  | dashboard      | Acceptance panels; probes; measured performance truth.                     |

Ad hoc specialists may be assigned for domains outside standing roster. Adding standing agent requires methodology decision or plan update.

## Ownership Contract

Every parallel assignment must include: identity, surface, specialization, assignment, risk tier, owned files/modules/artifacts, expected output, decision authority, review gates, test/verification expectation, handoff target, status recipient (usually Donna for Plan #10).

Parallel work allowed only when ownership boundaries are explicit. Two agents must NOT independently edit the same file/artifact unless one is clearly reviewer and one is clearly implementer, OR Donna explicitly authorizes the shared edit plan.

## Consensus Workflow

Low risk: single agent proceeds; checkpoint outcome.
Medium risk: owner drafts plan/patch; one peer review; Donna or lane owner authorizes.
High architectural risk: proposal → Candi methodology review (when applicable) → Texi architecture review → Donna engineering feasibility review → revision → PO/Donna tie-break (if project goals decide) → implementation authorization.

Dual-model review mandatory for R2/R3 only when: cross-surface behavior affected, model-family disagreement risk material, tool capability/prompt behavior affected, memory/routing semantics affected, OR Donna/Texi/Candi marks required. NOT mandatory for every R2 by default.

### Conflict routing

| Conflict type                      | Resolver                             |
| ---------------------------------- | ------------------------------------ |
| Prompt/method/rule/governance      | Candi                                |
| Architecture                       | Texi                                 |
| Engineering feasibility/sequencing | Donna                                |
| Product/project-goal tie           | PO / Donna under Plan #10            |
| Metrics/performance truth          | Porsche                              |
| Documentation SOR                  | Desiree (with Candi/Donna as needed) |

All resolutions become one of: ADR update, SPEC update, tracked CI item, postmortem/RCA memory (when caused by issue), checkpoint decision (when bounded to active task).

Architecture veto/revision uses existing `ReviewCompleted` signal type with explicit verdict semantics (`revisions_required`, `veto`, `accept_with_amendments`, `accepted`). No new signal type required.

## Method Fragments

Reusable governed methodology units, smaller than SPEC, more structured than prose. Answer: when should this trigger, who owns it, what context required, what output expected, what review gates apply, what memory should be read/written.

### Schema (yaml)

```yaml theme={null}
schema_version: 1
version: 1
id: method.<slug>
title: <short title>
status: draft|accepted|deprecated|superseded
source_of_record: prism_typed_artifact
generated_mirror_paths: [docs/method-fragments/<slug>.md]
authority_layer: global|tenant|org|project|user_session_runtime
owning_specialization: <specialization>
owner_identity: <identity>  # optional
applies_to_specializations: [<specialization>]
applies_to_surfaces: [codex, claude_code]
use_when: [<trigger>]
skip_when: [<non-trigger>]
risk_tier_default: R0|R1|R2|R3
risk_tier_override_allowed: true|false
required_context: [<memory domain or artifact>]
expected_outputs: [<artifact or result>]
required_prism_verbs: [<verb name>]
review_gates: [<identity or specialization>]
review_required: true|false
memory_writes: [<memory domain>]
conflict_policy: <routing rule>
telemetry_key: method.<slug>
supersedes: [<method id>]
superseded_by: [<method id>]
source_refs: [<path or artifact id>]
```

### Minimum acceptance requirements

A method fragment is not accepted until it exists as a Prism typed artifact in the database (SOR), `use_when`/`skip_when` both present, owner specialization named, applies-to specializations named, expected outputs named, risk tier named, risk-tier override behavior explicit, review gates explicit (or explicitly empty), review-required boolean explicit, memory writes explicit (or explicitly empty), telemetry key present, source refs present.

### Initial candidate fragments

| Method fragment                         | Owner       | Purpose                                                         |
| --------------------------------------- | ----------- | --------------------------------------------------------------- |
| `method.consensus.risk-tier-assignment` | Candi       | Classify work as R0-R3.                                         |
| `method.consensus.architecture-gate`    | Texi        | Trigger arch gate for R2/R3 work.                               |
| `method.conflict.prompt-governance`     | Candi       | Route prompt/method conflicts to Candi.                         |
| `method.parallel.ownership-contract`    | Donna/Candi | Require ownership fields before parallel work.                  |
| `method.review.dual-model`              | Texi/Candi  | Require Claude/Codex cross-model review for selected R2 work.   |
| `method.completion.done-definition`     | Donna       | Enforce design+built+tested+committed unless deferral approved. |

## Completion Semantics

For Plan #10, the operating contract defines "complete" as: designed, built, tested, committed, status reported to Donna, relevant checkpoint recorded, RCA committed to memory for any issue or dead end. Deferrals require Donna's knowledge and a good reason. Milestones are checkpoints, not rest stops.

This is operating-contract authority. SPEC-078 automation must NOT auto-enforce this definition while `PRISM_CONSENSUS_PARALLELISM_ENABLED=false`.

## Telemetry and Acceptance Panel

Porsche acceptance panels measure whether this standard improves engineering quality without creating hidden drag.

Minimum signals: risk-tier assignment events (proposed tier, final tier, setter, override reason); consensus loop lifecycle events (opened, review\_requested, amended, authorized, closed); review turnaround time; review gate status events (missing, requested, satisfied, waived); conflicts routed by type; Candi conflict resolutions; Texi architecture amendments; Donna implementation authorizations; override/deferral events (who authorized, why, expiry/follow-up); RCA count for consensus failures; method fragments surfaced; method fragments invoked; tasks blocked by missing required gates when flag enabled.

No performance claims may enter prompts or governance rules until measured.

## Storage / Memory Hooks

This SPEC does not define final memory storage. Blocker #5 (SPEC-079 Memory Domain Contracts) owns that. SPEC-079 must consume these terms: risk tier, risk\_tier\_assignment, method fragment, ownership contract, consensus loop, conflict resolution, review gate, implementation authorization, deferral, RCA.

Blocker #6 (Tri-Graph Governance Recall) should consume these graph entities: `MethodFragment`, `RiskTier`, `ReviewGate`, `ConsensusLoop`, `ConflictResolution`, `ImplementationAuthorization`. Minimum edges: `APPLIES_TO_SPECIALIZATION`, `REQUIRES_GATE`, `SATISFIES_METHOD`, `SUPERSEDES`.

## Implementation Phases

Phase 0 — Ratification only: SPEC review by Texi, Donna ratification, no behavior-changing code.

Phase 1 — Manual practice and docs: Desiree docs sweep; add accepted method-fragment templates; Candi maintains CI loop tracking; no automatic routing.

Phase 2 — Default-off advisory support (requires `PRISM_CONSENSUS_PARALLELISM_ENABLED=true`): surface applicable method fragments in `prism_start` or dedicated recall verb; emit advisory risk-tier recommendations; emit missing ownership-contract warnings. Phase 2 is advisory only — recommend/surface/warn, NOT block completion.

Phase 3 — Enforcement gates (requires separate implementation authorization): block completion when required gates missing; require explicit Donna override for deferrals; integrate with Tri-Graph Governance Recall once Blocker #6 ratifies.

## Acceptance Criteria

1. SPEC reviewed by Texi and ratified by Donna. ✓
2. Feature flag named and default-off invariant specified. ✓
3. Risk tiers R0-R3 defined with required workflow. ✓
4. Agent/tool boundary defined. ✓
5. Ownership contract defined. ✓
6. Conflict routing table defined. ✓
7. Method-fragment schema defined. ✓
8. Initial candidate fragments listed. ✓
9. SPEC-079 Memory Domain Contracts can consume this vocabulary without redefining terms. ✓
10. Telemetry events/fields listed. ✓
11. With feature flag unset/false, no live behavior changes. ✓
12. Method fragments specified as Prism typed artifacts in database SOR with docs mirrors generated from that source. ✓

## Review Decisions Folded in v0.2

1. Method fragments live as Prism typed artifacts in DB SOR with generated docs mirrors.
2. Dual-model review mandatory only for cross-surface/model/tool/prompt/memory/routing-sensitive R2/R3 or Donna/Texi/Candi-marked.
3. Risk tier proposed by owner, set/overridden by Donna for Plan #10, escalated by Texi/Candi for arch/gov risk; advisory recommends only.
4. Architecture veto/revision uses `ReviewCompleted` verdict semantics; no new signal type.
5. `prism_start` exposes compact counts/ids only; full retrieval via dedicated recall verb or future Tri-Graph.

## References

* Plan #10 v0.3 (Donna ownership map)
* ADR #47 v0.2 (Governance Layer Precedence + Override Semantics)
* SPEC-077 v0.2 (Governance Resolution + Boot Report)
* ADR #48 v0.2 (Identity / Specialization / Assignment / Style Model)
* SPEC-063 (Postmortem + Retrospective Discipline)
* Texi architectural review `a6a0242b`
* Texi clean signoff `17ff83d3`