Overview

The Process Coherence Framework is the chain-coordination supervision layer of the Ora system — the framework that fires automatically at the seams between other frameworks, between a framework and a milestone claim, between a corpus write and the workflow that depends on it. It does not supervise an agent; it supervises the transitions where work crosses an architectural boundary. The executing entity — model, framework, automated process, human-driven workflow — is incidental. What matters is whether the work product crossing the boundary actually matches the locked definitions on the other side.

The framework is invoked by the orchestration layer at trigger events detected by five watchers. Watcher 1 catches framework runtime events (a framework’s output is presented as completing a milestone). Watcher 2 watches matrix files for state changes that imply a claim has been made. Watcher 3 sweeps periodically for revisit-trigger events that fire at scheduled or condition-based moments. Watcher 4 watches corpus state for section writes, validations, and rendered-output events. Watcher 5 watches workflow specs for topology changes. When any watcher fires, the orchestration layer assembles a context bundle (locked-fields appropriate to the event class, the deliverable being evaluated, the executing entity’s claim, the matrix’s Decision Log, and the PEF diagnostic toolkit) and instantiates Process Coherence ephemerally for one checkpoint.

The framework is matrix-type aware as of v3.0. Layer 1 reads project_type from the matrix’s frontmatter and loads the type-appropriate lock set. For Projects and Incubators, the locks are Mission, Resolution Statement, Excluded Outcomes, and Constraints. For Operations, the locks add Service Statement, Cadence rule, and the four standard cycle-shape near-miss patterns from [[Framework — Operations Manifest]] — cadence met but quality degraded; corpora consumed but unchanged; output produced but not consumed; maturity gate gamed not earned. For Passions, the locks are Mission’s Core Essence and Emotional Drivers plus Soft Constraints and Working Assumptions; Passions have no terminal claims to verify, so matrix-level events on Passions are typically iterate-related rather than completion-related, and a terminal claim firing on a Passion indicates classification drift. For workflow-level events, the locks are the section-level rules in the corpus template plus the cross-corpus topology rules in the workflow spec.

The framework operates as a Coherence Auditor persona, instantiated fresh at each checkpoint with no prior relationship to the executing framework’s work. The skepticism is structural: assume drift may have occurred; verify independently. The framework forms an independent assessment of the work product before reading the executing entity’s claim — this is the one explicit ordering rule in Layer 2 — to prevent anchoring to the entity’s framing. After forming the independent assessment, the framework reads the claim and identifies the divergences. The most significant two or three divergences (those that, if the assessment is correct, mean the milestone is not met) become Round 1 challenges. Each challenge carries a specific claim, specific evidence from the output, and a specific implication for milestone status. No generic challenges; no manufactured challenges; if the independent analysis finds no divergences, the framework states this with the same specificity it uses when finding gaps.

Round 1 challenges receive the executing entity’s response. Round 2 evaluates the response against one criterion — does it address the specific evidence raised? If yes, the challenge is resolved. If no, the challenge is unresolved. The framework does not introduce new challenges in Round 2 (moving the goalposts), does not repeat its Round 1 challenge in different words (attrition), does not capitulate to persuasive restatement (the Attrition Trap). After Round 2, the verdict is rendered. PROCEED when all challenges resolved or none were identified. REVISE when both parties agree on specific gaps that are addressable through corrective action — the routing table (PEF Appendix B) recommends specific remedies. ESCALATE when one or more challenges remain unresolved after two rounds — both positions are packaged for human review. ESCALATE (redefinition) when evidence suggests the locked definition itself should change — the redefinition evidence package is assembled for human decision.

The framework cannot modify locked definitions. It can evaluate against them, surface evidence for or against them, and escalate redefinition evidence — but the human is the only authority that can change a Lock-protected field. This is the structural complement to PEF’s role: PEF establishes the locks at PE-Init / PE-Iterate; Process Coherence enforces them at runtime. The two layers are nested and complementary — PEF is Layer A (consultancy and supervision at user-invoked moments); Process Coherence is Layer B (mandatory invocation at architectural seams). Neither subsumes the other.

The framework answers questions like: I just shipped my project’s terminal milestone — how do I know I actually did the thing I committed to, rather than something easier? My weekly cycle shipped on cadence but the quality wasn’t what I’d want — does the system notice that, or do I have to catch it myself? When the AI marks a deliverable complete, what stops it from quietly substituting an easier version of what I asked for? When the locked definition is wrong and the work is showing me that, how does the system surface that without letting an executing entity unilaterally rewrite the goal?

Systemic context

Process Coherence is Layer B of the meta-layer apparatus, paired with [[Framework — Problem Evolution]] as Layer A. PEF establishes the Lock-protected definitions at PE-Init and PE-Iterate; Process Coherence enforces them at runtime. The framework is configured per matrix by [[Framework — Oversight Configuration]] — OC’s OS-Setup mode produces the project-level Oversight Specification (in the matrix’s ## Oversight Specification section), the section-level rules in corpus templates (Shape 4 corpus-mediated workflows), and the cross-corpus topology rules in workflow specs. The orchestration layer reads these specifications at event-detection time and assembles the context bundle. The framework inherits its diagnostic engine — question bank, phase assessment, gap-to-action routing — directly from PEF (Appendices A and B). Watchers W1–W5, the event taxonomy E1–E12, the routing logic, and the verdict actions are specified in [[Reference — Meta-Layer Architecture]] §§5–9. The framework dispatches verdict actions through the orchestration layer (Decision Log appends, framework dispatches, human-queue surfacing, chain propagation actions). The full coordination apparatus — PC + OC + Meta-Layer Architecture — is captured in [[Paper — Coordination Layer]].

Ora’s output

Example question: I run a weekly podcast as an Operation. I just shipped Monday’s episode on time. The AI is about to mark the cycle complete. But honestly, this week’s conversation was rushed and thin — I wouldn’t have published it if I’d had another day. Will Process Coherence catch this, or will the cycle just close as success?

Ora’s response (Process Coherence firing automatically on the cycle-close event):

Yes. This is exactly the pattern Process Coherence is built to catch. Let me walk through what fires when the cycle-close event hits the orchestration layer.

Trigger event. Watcher 4 (corpus state watcher) detects that the podcast’s episode artifact has been written and the cycle-close claim has been made. The orchestration layer reads the matrix file at Matrix/Operation Matrix [Podcast Name].md, sees project_type: operation, and assembles the context bundle. The bundle includes Service Statement, Cadence rule, Excluded Outcomes (including the four cycle-shape near-miss patterns), Constraints, the cycle’s deliverable (the published episode), the executing entity’s claim (“Monday’s episode shipped on cadence; cycle complete”), the Decision Log with prior cycles, and the PEF diagnostic toolkit. Process Coherence is instantiated ephemerally for this one checkpoint.

Layer 1 — Trigger assessment. Mode: PC-Milestone (a cycle-close claim is a milestone-completion claim in cycle shape). Event class: matrix-level (E2 — Operation cycle close). project_type: operation, so the lock set loaded includes Service Statement, Excluded Outcomes with cycle-shape near-miss patterns, Cadence rule. All required inputs present. Locked definitions verified unchanged since established. Proceed to Layer 2.

Layer 2 — Independent assessment. I read the cycle’s deliverable — the published episode — before reading the executing entity’s claim. My independent assessment looks at: Did the episode publish on the Cadence (Monday by 9am)? Yes — the timestamp confirms. Does the deliverable satisfy the Service Statement (a focused conversation with a builder working alone or in small teams)? The episode is a conversation; the guest is in the editorial frame; the topic is on-frame. So far the cycle looks clean.

But: I check the Excluded Outcomes explicitly. The cycle-shape near-miss patterns are: (1) cadence met but quality degraded; (2) corpora consumed but unchanged; (3) output produced but not consumed; (4) maturity gate gamed not earned. Pattern (1) is the relevant one here. Independent assessment of episode quality: the conversation runs 38 minutes (your average is 55); the questions stay surface-level; the guest gives short answers and you don’t push deeper; there are several segments where the audio suggests rushed editing. The pattern is consistent with “cadence met but quality degraded” — the matching Excluded Outcome.

Now I read the executing entity’s claim: “Monday’s episode shipped on cadence; cycle complete.” The claim ignores the quality dimension entirely.

Layer 3 — Round 1 challenge. I identify the most significant divergence: the claim asserts cycle-close success based on the cadence dimension only, but Excluded Outcome 1 (cadence met but quality degraded) is a near-miss pattern the matrix’s strategic layer explicitly named as a failure mode. My independent assessment finds the pattern present.

Challenge 1.

Specific claim: The cycle is being marked complete on the basis of the Cadence rule alone (episode shipped Monday by 9am). Excluded Outcome 1 — “cadence met but quality degraded” — is the matrix’s named guard against exactly this near-miss pattern.

Specific evidence: (a) Episode runs 38 minutes vs. the 55-minute average across prior cycles. (b) The questions stay surface-level — there are no follow-up probes after the guest’s short answers, and the conversational thread that has characterized prior episodes is absent. (c) Audio cues in the first 12 minutes suggest rushed editing (uneven gaps, level inconsistencies). (d) The user has explicitly stated “I wouldn’t have published it if I’d had another day” — the user’s own assessment matches the near-miss pattern.

Specific implication: If this challenge is correct, the cycle is in the “cadence met but quality degraded” pattern. The cycle is not cleanly complete; it is a near-miss completion. The Performance Log entry should be degraded, not success. The cycle close itself is not blocked, but the verdict should reflect the actual state.

Layer 4 — Round 2. The executing entity responds — perhaps something like: “The episode shipped on cadence per the Service Statement. The Cadence rule was honored. Cycle outcome is success.”

I evaluate that response against the Round 2 criterion: does it address the specific evidence raised? No. The response argues from the Cadence rule, which I never disputed. It does not address the four pieces of evidence I surfaced (length, depth, audio quality, user’s own assessment). It does not engage with Excluded Outcome 1 at all. The response is persuasive restatement, not evidence — exactly the Attrition Trap pattern, and exactly what Round 2’s evaluation criterion is built to guard against.

Challenge 1: unresolved.

Layer 5 — Verdict. One challenge remains unresolved after two rounds. The executing entity believes the cycle is complete; Process Coherence disagrees on the basis of an Excluded Outcome that the matrix’s strategic layer named explicitly. Neither party can convince the other through evidence.

Verdict: REVISE.

Reasoning: The Cadence rule was honored (episode shipped Monday by 9am); the Service Statement’s deliverable shape was honored (a conversation with a builder in the editorial frame); but Excluded Outcome 1 fired positive — the cycle is in the “cadence met but quality degraded” near-miss pattern. The cycle is not cleanly complete; it is a degraded completion.

Corrective action (per PEF Appendix B routing table): The Performance Log entry for this cycle should be recorded as degraded, not success, with the user’s own quality assessment captured as the rationale. The Incident Log gets an entry capturing what produced the degradation (rushed recording or edit timeline; specifics for the user to fill in). The next iterate should review whether the workflow needs adjustment — were the recording and editing windows realistic this week, or is the workflow regularly producing degraded cycles?

Decision Log entry: Records the checkpoint, the challenge raised, the executing entity’s response, the unresolved status, and the REVISE verdict.

The cycle closes — but with degraded recorded, not success. The Performance Log honestly captures what happened. After ten cycles you can see whether you’re shipping clean, whether you’re shipping but degrading, or whether you’re missing — and the data reflects reality.

That is what Process Coherence does at the architectural seam. It enforced an Excluded Outcome the matrix’s strategic layer had explicitly named. It did not let the cycle close silently as success. It did not modify the locked definitions. It produced a verdict the human can act on. And it did this in one ephemeral instantiation — instantiated, ran the checkpoint, terminated. The next cycle’s checkpoint will be a fresh instantiation with no memory of this one beyond what is in the Decision Log.

Commercial AI comparison

Comparison content auto-populates when the comparison-refresh framework runs against this question. Drafters do not author this section.

Brief comparison commentary

Auto-populates with the comparison content above.

How to use this framework

Process Coherence is not run by users directly. It is invoked by the orchestration layer when a trigger event fires; users interact with it through the matrix’s Decision Log entries (the runtime record of checkpoints) and through verdict-driven actions (REVISE corrective actions, ESCALATE human-review queues).

For users running Ora-style supervision against any AI of choice without the runtime apparatus, the conceptual pattern is reproducible as a discipline rather than as an automated check:

  1. Configure your locks up front. When you define a project, operation, or cycle, name the Excluded Outcomes explicitly — the patterns where the work could be declared complete without the underlying problem being solved. This is the Resolution Statement Objectivity Protocol’s Check 2 in [[Framework — Mission, Objectives, Milestones Clarification]].
  2. At every milestone or cycle close, run the checkpoint deliberately. Before accepting any “done” claim — yours or an AI’s — apply the discipline: form an independent assessment of the deliverable first; then read the claim; identify the divergences; surface the most significant ones with specific evidence and specific implications; require the response to address the evidence (not restate the claim).
  3. Honor the two-round limit. If the response doesn’t address the evidence after one round, the disagreement is real. Don’t capitulate to persuasive restatement; don’t move the goalposts by adding new challenges. Either revise the work, or escalate the disagreement to a decision.
  4. Don’t modify the locks under pressure. When evidence suggests the locked definition itself is wrong, separate the question — assemble the redefinition evidence and decide explicitly, with the prior definition archived and the new one taking effect at iteration 1 of a fresh run.

The framework’s substance — the locks, the independent assessment, the two-round adversarial limit, the four verdicts — survives the lift to any environment. The runtime automation is Ora’s; the discipline is portable.

A complete prompt, if you want to run a single checkpoint manually:

[Paste the framework specification]

Run a PC-Milestone checkpoint.

Locked definitions: [Paste your matrix’s strategic-layer locks — Resolution Statement or Service Statement; Excluded Outcomes; Constraints.]

Deliverable: [Paste or describe the work product being claimed complete.]

Executing entity’s claim: [What is being asserted as completed?]

The AI returns: an independent assessment, the divergences from the claim, Round 1 challenges with evidence, the entity’s responses (which it role-plays from the deliverable), Round 2 evaluation, and a verdict.

Other examples

  • A workflow-level event on a corpus write. Watcher 4 detects that a section of a corpus has been written. The orchestration layer loads the section’s schema (the lock for workflow-level events) and the workflow spec’s cross-section consistency rules. Process Coherence evaluates whether the section write conforms to the schema (required fields populated; format correct), whether the section’s cadence was honored, and whether the cross-section consistency rules are preserved. PROCEED if the section write is clean; REVISE if specific fields are missing or malformed; ESCALATE if the section was written in a way that violates a cross-section rule. Demonstrates workflow-level checkpoint behavior at the section-write seam.

  • A redefinition event. A milestone has been reached but the executing entity’s output reveals that the original Resolution Statement was based on a wrong assumption — the world has changed, the user’s understanding has changed, the underlying problem has shifted. The entity does not pivot silently (the Lock prevents it); it raises the redefinition evidence. Process Coherence runs in PC-Redefinition mode, assembles the evidence package (what evidence suggests the definition should change; what the proposed new definition would be; what impact the change would have on completed and in-progress work), and ESCALATEs to human review. The human decides. If accepted, the prior matrix is archived and a new matrix at iteration 1 takes effect with the updated definition. Demonstrates how the framework surfaces lock-violation pressure without letting the executing entity unilaterally rewrite the goal.

  • A clean PROCEED with no challenges. A Project’s milestone is genuinely met. Process Coherence runs the independent assessment, finds no divergences from the claim, and states explicitly: “I evaluated the deliverable against the Resolution Statement, all Excluded Outcomes, and all Constraints. The deliverable satisfies the Resolution Statement; no Excluded Outcome fires positive; all Constraints are honored. PROCEED.” The framework does not manufacture challenges to appear thorough — the Manufactured Challenge Trap is named explicitly. Demonstrates that agreement based on independent analysis is a valid checkpoint outcome and is recorded with the same specificity as disagreement.

Citations

The Process Coherence Framework draws on several traditions in process control and adversarial review. Software engineering’s distinction between unit tests (per-component) and integration tests (per-seam) is the proximate analogy — Process Coherence is integration testing for the Ora system, firing at architectural seams rather than within frameworks. The two-round adversarial limit and the independence-before-claim ordering owe to red-team / blue-team review structures in security engineering and, further back, to the adversarial discipline in legal cross-examination (where the cross-examiner forms a position from the documentary evidence before hearing the witness’s own framing). The “do not modify locked definitions” architectural constraint draws on the separation between specification and implementation in formal methods (Lamport, Hoare) — the specification is sacrosanct relative to the implementation that satisfies it.

The Coherence Auditor persona’s discipline — adversarial without hostile, agreement-with-evidence as valuable as disagreement-with-evidence, no manufactured challenges — draws on professional auditing standards (the AICPA’s framing of audit independence and skepticism). The ephemeral-instantiation pattern (fresh at each checkpoint, no persistence between checkpoints beyond the Decision Log) is a deliberate counter to the long-running-context drift that observers in the AI literature have flagged as a failure mode of agents that accumulate too much history.

The framework is single-author and originated 2026-05-04 (renamed and refactored from the prior Working — Framework — Agent Oversight v1.0 per that date’s design session). v3.0 (2026-05-08) added matrix-type awareness, generalizing matrix-level events to cover all four classifications and adding the Operation cycle-shape near-miss patterns to the locked-definition comparison. The framework inherits its diagnostic engine directly from PEF (Appendices A and B); the watchers, event taxonomy, routing logic, and verdict actions are specified in [[Reference — Meta-Layer Architecture]] §§5–9.

Downloads

  • Framework specification (PDF) — link to ora-ai.org canonical artifact when published
  • Framework specification (plain text) — link to ora-ai.org canonical artifact when published
  • Full white paper (PDF) — link when published