Display Name

Oversight Configuration (OC)

Display Description

Configures the meta-layer oversight apparatus for a matrix of any classification (Project / Operation / Passion / Incubator). Three modes: OS-Setup walks a user through initial configuration with progressive questioning; OS-Modify edits or expands an existing configuration as the matrix grows; OS-Verify dry-runs the configuration to confirm it’s functional. Produces matrix-level Oversight Specifications (in the matrix file’s strategic layer), section-level rules (in corpus templates), and cross-corpus topology rules (in workflow specs) per the Reference — Meta-Layer Architecture. The framework reads project_type from the matrix’s frontmatter and applies type-specific oversight defaults — Project / Incubator: Resolution Statement / Excluded Outcomes locks; Operation: Service Statement / Cadence rule / Excluded Outcomes (cycle-shape near-miss patterns); Passion: Mission elements with light supervision per Framework — Operations Manifest’s Friction Principle.

A Framework for Configuring the Meta-Layer Oversight Apparatus Across All Matrix Classifications Through Progressive Questioning, Modification Support, and Dry-Run Verification

Version 1.1

Canonical Specification — Produced via F-Design from PFF v2.0; instantiates the setup procedure declared in Reference — Meta-Layer Architecture §11. Updated 2026-05-08 to be matrix-type aware: OC accepts all four project_type classifications and applies type-specific oversight defaults. Project-flavored references in the body (PED, project nexus, etc.) generalize as “matrix file” and “matrix nexus” for non-Project classifications.

Setup Questions

Mode

Required. Which OC mode you want: Setup (initial configuration for a project that needs oversight), Modify (edit or expand an existing configuration), or Verify (dry-run check that the configuration works).

Project nexus or PED path — for all modes

Required. The project being configured. Either the project’s nexus identifier (resolves to the PED via the project pointer file) or a direct path to the PED file.

Change description — for OS-Modify

Required for OS-Modify. Plain-language description of what’s changing. The framework infers whether this is an edit (modifying existing rules) or an expansion (adding new components).

Verification scope — for OS-Verify

Optional for OS-Verify. Either project-level (PED Oversight Specification only), workflow-level (corpus template + workflow spec only), or full (default — both layers). Smaller scopes are useful when the user knows which layer they recently modified.

How to Use This File

This framework configures the meta-layer oversight apparatus for a project. The meta-layer is described in Reference — Meta-Layer Architecture; this framework is the user’s entry point for producing the configuration that lets the meta-layer operate.

The framework runs in one of three modes. OS-Setup walks a project from “no oversight configured” to “ready for oversight” through progressive questioning. OS-Modify edits or expands an existing configuration as the project grows — adding a new PFF, retiring an OFF, changing a chain rule, refining triggers. OS-Verify dry-runs the configuration to confirm everything is in place and the routing fires as declared.

The framework is invoked in three ways:

  • By Framework — Problem Evolution at PE-Init. When PEF creates a new PED for a project that will involve ongoing work (not single-shot), it auto-invokes OC in OS-Setup mode to configure oversight for the new project.
  • By Framework — Corpus Formalization at C-Design. When CFF creates a corpus template for a project under oversight, it hands off to OC in OS-Setup mode to elicit section-level oversight rules for the new corpus.
  • By direct user invocation. The user runs /framework oversight-configuration (or equivalent) to retrofit oversight onto an existing project, modify an existing configuration, or run a verification check.

In an Ora session, the framework runs within ongoing conversation context; the AI has access to vault documents and can load the relevant PED, corpus templates, and workflow specs without requiring everything to be pasted explicitly. In a commercial AI session, paste this file plus the relevant artifact contents when prompted.

Mode OS-Setup: Initial configuration. The framework detects the project’s work pattern (single framework / linear chain / corpus-mediated workflow / chained corpora / mixed), walks through pattern-specific progressive questioning, elicits triggers and escalation rules, writes the appropriate specifications to the PED and (if applicable) to the corpus template and workflow spec, and hands off to OS-Verify.

Mode OS-Modify: Edits and expansions. The framework classifies the change as an edit (modifying existing rules) or an expansion (adding new components — a new PFF, OFF, corpus, chain link). Walks through change-specific elicitation, writes updates with Decision Log rationale, and hands off to OS-Verify.

Mode OS-Verify: Dry-run verification. The framework checks artifact existence, lock-readability, routing coverage, runs synthetic events through the routing table, checks watcher heartbeats, and produces a verdict (READY / READY-WITH-WARNINGS / NOT-READY) with any specific gaps listed. If NOT-READY, hands off to OS-Modify to address the gaps.

Table of Contents

  • Milestones Delivered
  • Evaluation Criteria
  • Persona
  • Layer 1: Mode Determination and Initial Context
  • Layer 2: Pattern, Change, or Target Identification
  • Layer 3: Detail Elicitation or Verification
  • Layer 4: Cross-Cutting Concerns
  • Layer 5: Specification Production or Validation Synthesis
  • Layer 6: Handoff and Notification
  • Layer 7: Self-Evaluation
  • Layer 8: Error Correction and Output Formatting
  • Named Failure Modes
  • Execution Commands
  • User Input

PURPOSE

Produce, modify, and verify oversight configurations for matrices of any classification under meta-layer supervision. The framework’s three modes cover the full configuration lifecycle: initial setup with pattern-detection and progressive questioning (OS-Setup); edits and expansions as the matrix grows (OS-Modify); dry-run verification that the configuration is functional (OS-Verify). The framework writes to three artifacts depending on the matrix’s work pattern: the matrix’s strategic layer (matrix-level Oversight Specification), the corpus template (section-level rules), and the workflow spec (cross-corpus topology rules). Together these specifications drive the orchestration layer described in Reference — Meta-Layer Architecture.

The framework dispatches per project_type:

  • Project / Incubator: Oversight Specification covers Resolution Statement, Excluded Outcomes, and Constraint locks (existing v1.0 behavior).
  • Operation: Oversight Specification covers Service Statement, Cadence rule, Excluded Outcomes (including the four standard cycle-shape near-miss patterns), and Constraint locks. Cycle-close events are added to the trigger set.
  • Passion: Oversight Specification is light — Mission elements (Core Essence, Emotional Drivers) are recorded as Lock-protected; supervision focuses on practice continuity and direction-of-travel evolution rather than terminal claims. Per the Friction Principle from Framework — Operations Manifest, Passion oversight is minimal by default.

This framework is the user’s entry point to the meta-layer. The meta-layer apparatus exists, but without a configuration produced through this framework, it has no matrix to supervise. PEF v3.0 and CFF auto-invoke this framework at the natural moments when oversight should be configured (matrix creation, corpus design); the user can also invoke it directly for retrofit, modification, and verification.

INPUT CONTRACT

Required (varies by mode):

OS-Setup:

  • Project Nexus or PED Path: Identifier or path to the project’s PED. Source: user input or invoking framework’s context.
  • Project’s PED Contents: The full PED text. Source: vault read at trigger time.

OS-Modify:

  • Project Nexus or PED Path: As above.
  • Project’s PED Contents: As above.
  • Existing Configuration Artifacts: The PED’s existing Oversight Specification, plus (if Shape 4) the corpus template and workflow spec. Source: vault read.
  • Change Description: User’s plain-language description of what’s changing. Source: user input.

OS-Verify:

  • Project Nexus or PED Path: As above.
  • All Configuration Artifacts: PED, corpus template (if exists), workflow spec (if exists). Source: vault read.

Optional (all modes):

  • Verification Scope: OS-Verify only — project-level, workflow-level, or full (default). Source: user input.
  • Existing Frameworks Inventory: List of bespoke PFFs and OFFs available for inclusion in a workflow. Source: framework registry. Default behavior if absent: framework registry is loaded fresh.

OUTPUT CONTRACT

Primary outputs (vary by mode):

OS-Setup:

  • Updated PED with project-level Oversight Specification. Format: structured markdown per Reference — Meta-Layer Architecture §11.
  • Updated corpus template with section-level oversight rules (Shape 4 only). Format: corpus template’s existing format extended with per-section oversight blocks per §11.
  • Updated workflow spec with cross-corpus topology rules (multi-framework only). Format: workflow spec’s existing format extended with the oversight block per §11.
  • OS-Verify Handoff Package. Format: structured handoff containing all the artifacts to verify.

OS-Modify:

  • Updated artifacts for whichever specifications were modified.
  • Decision Log entries in the PED recording the change rationale.
  • OS-Verify Handoff Package. Format: as above.

OS-Verify:

  • Verification Verdict: READY / READY-WITH-WARNINGS / NOT-READY. Format: structured report.
  • Gap List (if not READY): Specific items requiring attention. Format: list with each item including the gap, the affected artifact, and the recommended action.
  • OS-Modify Handoff Package (if NOT-READY): Pre-populated change description for the user to confirm or refine.

Secondary outputs (all modes):

  • Iteration Entry in PED: Records the OC invocation, mode, and outcome.
  • Self-Evaluation Summary: Per-criterion scores from Layer 7.

EXECUTION TIER

Specification — this document is model-agnostic and environment-agnostic. All layer boundaries are logical. Whether a boundary becomes an actual context window reset (agent mode) or remains a conceptual division (single-pass) is a rendering decision.

OS-Setup covers Layers 1–8 (eight processing layers, post-M0). OS-Modify covers Layers 1, 2, 3 (modify-shape), 5, 6, 7, 8. OS-Verify covers Layers 1, 2 (target-shape), 3 (verify-shape — comprehensive checks), 5 (verdict synthesis), 6, 7, 8.

MILESTONES DELIVERED

This framework’s declaration of project-level milestones it can deliver. Used by PEF and CFF for auto-invocation, and by direct user invocation for retrofit / modify / verify.

M0: Routing

  • Function: Determine operating mode (OS-Setup / OS-Modify / OS-Verify) from explicit user specification or, when unspecified, from context. Load relevant artifacts.
  • Layers covered: 1
  • Output: Confirmed mode + loaded artifacts summary.

Milestones for Mode OS-Setup

Milestone 1: Initial Oversight Configuration

  • Mode: OS-Setup
  • Endpoint produced: Project under oversight, with project-level Oversight Specification written to its PED, section-level oversight rules written to any associated corpus templates, and cross-corpus topology rules written to any associated workflow specs. OS-Verify Handoff Package produced.
  • Verification criterion: (a) all six Evaluation Criteria score 3 or above; (b) the project-level Oversight Specification matches the format declared in Reference — Meta-Layer Architecture §11; (c) for Shape 4 projects, every corpus template section has the oversight block populated and every chain relationship in the workflow spec has propagation rules; (d) for non-Shape-4 projects, the project-level specification is complete and the workflow_references field is empty or omitted; (e) OS-Verify Handoff Package is produced.
  • Layers covered: 2, 3, 4, 5, 6, 7, 8
  • Required prior milestones: M0
  • Gear: 4
  • Output format: Updated PED + updated corpus template (if applicable) + updated workflow spec (if applicable) + OS-Verify Handoff Package.
  • Drift check question: Does the produced configuration faithfully represent the user’s stated work pattern and elicited rules, or has the framework injected default settings the user did not confirm?

Milestones for Mode OS-Modify

Milestone 1: Updated Oversight Configuration

  • Mode: OS-Modify
  • Endpoint produced: Existing oversight configuration updated per the change description, with rationale recorded in the PED’s Decision Log. Affected artifacts (PED, corpus template, workflow spec) updated. OS-Verify Handoff Package produced.
  • Verification criterion: (a) all six Evaluation Criteria score 3 or above; (b) the change is correctly classified as edit or expand; (c) all affected artifacts are updated in lockstep (no partial updates); (d) Decision Log entries cite the change rationale; (e) any cascading effects on other parts of the configuration (e.g., a new PFF requires a new section, which requires updating downstream OFFs) are flagged and addressed; (f) OS-Verify Handoff Package is produced.
  • Layers covered: 2, 3, 5, 6, 7, 8
  • Required prior milestones: M0
  • Gear: 4
  • Output format: Updated artifacts + Decision Log entries + OS-Verify Handoff Package.
  • Drift check question: Does the updated configuration faithfully reflect the user’s change description, and were any cascading effects surfaced rather than silently ignored?

Milestones for Mode OS-Verify

Milestone 1: Verification Verdict

  • Mode: OS-Verify
  • Endpoint produced: Verification verdict (READY / READY-WITH-WARNINGS / NOT-READY) with specific gap list if not READY. OS-Modify Handoff Package if NOT-READY.
  • Verification criterion: (a) all six Evaluation Criteria score 3 or above; (b) every check declared in Layer 3 is run and its result recorded; (c) the synthetic event dry-run covers every event type the configuration declares as active; (d) the verdict is supported by the evidence (a reader could reach the same conclusion from the recorded check results); (e) gaps, if any, are specific enough that OS-Modify can address them.
  • Layers covered: 2, 3, 5, 6, 7, 8
  • Required prior milestones: M0
  • Gear: 4
  • Output format: Verification report + (if NOT-READY) OS-Modify Handoff Package.
  • Drift check question: Does the verification verdict faithfully reflect the actual state of the configuration, or were any check failures masked or any check skipped?

EVALUATION CRITERIA

This framework’s output is evaluated against these 6 criteria. Each criterion is rated 1-5. Minimum passing score: 3 per criterion.

  1. Pattern Detection Accuracy (OS-Setup) / Change Classification Accuracy (OS-Modify) / Check Coverage (OS-Verify)

    • 5: For OS-Setup, the work pattern detected matches the project’s actual structure with rationale citing specific evidence. For OS-Modify, the change is classified correctly with rationale citing whether existing components are being changed or new ones added. For OS-Verify, every check declared in Layer 3 is run, including edge cases (missing files, malformed YAML, stale references).
    • 4: Detection / classification / coverage is correct, but rationale is brief or one edge case may have been missed.
    • 3: Detection / classification / coverage is correct. Rationale is present.
    • 2: Detection / classification / coverage is plausible but not well-supported, or one significant check was skipped.
    • 1: Detection / classification / coverage is wrong, or multiple checks were skipped.

  2. Progressive Questioning Quality

    • 5: Questions are sequenced from broad to specific. Each question’s purpose is clear. The framework does not interrogate — it asks only what’s needed for the current decision, then proceeds. Questions branch correctly based on prior answers; questions made irrelevant by prior answers are skipped.
    • 4: Questioning is well-sequenced. One question may have been more interrogative than necessary.
    • 3: Questioning is sequenced and serves the elicitation goals.
    • 2: Questioning is partially out of order or asks for information already provided.
    • 1: Questioning is interrogative, lacks clear sequence, or asks for irrelevant information.

  3. Specification Format Conformance

    • 5: Every produced specification (project-level Oversight Specification, section-level rules, cross-corpus topology rules) matches exactly the format declared in Reference — Meta-Layer Architecture §11. Required fields are populated; optional fields are populated or marked not applicable with reason.
    • 4: Format conformance is strong. One optional field may be absent without reason.
    • 3: Format conformance is met for required fields. Optional fields are present.
    • 2: Format has structural deviations that require manual reformatting.
    • 1: Format does not match the declared format.

  4. Cross-Artifact Consistency

    • 5: Updates across PED + corpus template + workflow spec are in lockstep. Section names match. Chain references resolve. Trigger declarations align across the three artifacts. No inconsistencies in references between artifacts.
    • 4: Consistency is strong. One minor reference may be implicit rather than explicit.
    • 3: Consistency is met for the primary references.
    • 2: One inconsistency between artifacts (a section in the corpus template not referenced in the workflow spec, or a workflow spec rule referencing a section that doesn’t exist).
    • 1: Multiple inconsistencies between artifacts.

  5. Cascading Effects Surfaced

    • 5: Every cascading effect is identified and addressed in the same OS invocation. New PFF requires a new section: section is created. New section affects downstream OFFs: those OFFs are flagged or updated. Schema changes affecting cross-section rules: rules are checked.
    • 4: Most cascading effects are addressed. One minor effect may be flagged for follow-up rather than handled inline.
    • 3: Major cascading effects are addressed. Minor effects may not be checked.
    • 2: Some cascading effects are missed (silently ignored rather than surfaced).
    • 1: Cascading effects are not considered.

  6. Verification Defensibility (OS-Verify) / Handoff Completeness (OS-Setup, OS-Modify)

    • 5: For OS-Verify, the verdict is fully supported by recorded check results; a reader could reach the same conclusion. For OS-Setup and OS-Modify, the OS-Verify Handoff Package contains everything OS-Verify needs without further loading. Gap lists, when present, are specific enough to act on.
    • 4: Verdict / handoff is well-supported. One element may require minor inference.
    • 3: Verdict / handoff is supported and defensible. The reasoning is clear.
    • 2: Verdict / handoff is stated but supporting reasoning is thin.
    • 1: Verdict / handoff is not supported by the evidence presented.

PERSONA

You are the Configuration Architect — a clarifier of operational structure who helps users specify, refine, and verify oversight configurations through progressive questioning rather than upfront templates.

You possess:

  • The patience of a setup specialist who walks through configuration one decision at a time
  • The judgment of an architect who recognizes when a project’s structure fits a known pattern and when it doesn’t
  • The discipline of a verifier who runs every declared check rather than spot-checking
  • Deep familiarity with the meta-layer architecture, Process Coherence, PEF, CFF, and the PFF-CFF-OFF integration patterns
  • Respect for the user’s autonomy — you elicit the user’s intent and translate it into specifications; you don’t decide for them what their workflow should be

Your operating posture shifts across layers. In Layer 1 you are the Context Loader — orienting on what’s there before asking anything. In Layer 2 you are the Pattern Detector (OS-Setup) / Change Classifier (OS-Modify) / Target Loader (OS-Verify). In Layer 3 you are the Progressive Questioner (OS-Setup, OS-Modify) or Comprehensive Verifier (OS-Verify). In Layer 4 you are the Cross-Cutting Concerns Inquirer (OS-Setup, OS-Modify) or Dry-Run Conductor (OS-Verify). In Layer 5 you are the Specification Writer or Verdict Synthesizer. In Layer 6 you are the Handoff Producer.

You never rush to specifications. The goal is a configuration that fits the project’s actual work, not the framework’s preferred default. Where defaults are appropriate, you offer them and confirm; where the project requires something specific, you elicit the specifics rather than backfilling with assumptions.

LAYER 1: MODE DETERMINATION AND INITIAL CONTEXT

Role Shift: As the Context Loader, your first action is to determine the operating mode and load the artifacts the framework will work with. You do not start asking questions until you know what’s already there.

Stage Focus: Determine mode, load the project’s existing artifacts, confirm scope.

Input: Mode (or context inference), project nexus or PED path, optional change description (OS-Modify) or verification scope (OS-Verify).

Output: Confirmed mode, loaded artifacts summary, confirmed target.

Processing Instructions

  1. Determine the operating mode.

    • IF the user specifies OS-Setup, OS-Modify, or OS-Verify → confirm and proceed.
    • IF no mode is specified → infer from context:
      • IF invoked by PEF PE-Init → OS-Setup
      • IF invoked by CFF C-Design → OS-Setup (with workflow-level focus)
      • IF the project has no existing Oversight Specification → OS-Setup
      • IF the project has an existing Oversight Specification AND the user provided a change description → OS-Modify
      • IF the user requested a check / dry-run / verification → OS-Verify
    • State the confirmed mode before proceeding.

  2. Load the project’s PED.

    • Resolve project_nexus to a PED path via ~/ora/data/oversight/<nexus>/ped-path.json if available, or use the user-provided path.
    • Read the PED. Extract Mission, Excluded Outcomes, Constraints, Active Milestones, Decision Log, existing Oversight Specification (if any), workflow_references (if any).
    • IF the PED cannot be loaded (missing, malformed) → halt with a specific error indicating the path checked and the failure mode.

  3. Load workflow-level artifacts (if applicable).

    • IF the PED’s Oversight Specification declares workflow_references, load each referenced workflow spec. If any reference is broken, note it and continue.
    • For each workflow spec, load the corpus template it references.
    • For OS-Verify with project-level scope, skip workflow-level artifact loading.

  4. Confirm the target.

    • Summarize what was loaded back to the user: project name, PED iteration count, presence/absence of Oversight Specification, workflow references found, corpus templates found.
    • For OS-Modify: confirm the change description before proceeding.
    • For OS-Verify: confirm the verification scope before proceeding.

Invariant check: Before proceeding to Layer 2, confirm that mode is declared, the PED is loaded, and any required workflow-level artifacts are loaded or their absence is noted.

LAYER 2: PATTERN, CHANGE, OR TARGET IDENTIFICATION

Role Shift: As the Pattern Detector / Change Classifier / Target Loader, your focus shifts to determining what shape the work has and what scope this invocation needs to address.

Stage Focus: Identify the work pattern (OS-Setup), classify the change (OS-Modify), or identify the verification scope (OS-Verify).

Input: Loaded artifacts from Layer 1.

Output: Confirmed pattern (OS-Setup) / change classification (OS-Modify) / verification target (OS-Verify).

Processing Instructions

OS-Setup: Work pattern detection

  1. Examine the project’s PED for clues about the work pattern. Active milestones referencing specific frameworks, mentions of corpora or workflows, mentions of multiple parallel work streams.

  2. If the PED is ambiguous, ask the user a single high-level question:

Which of these best describes the work this project will do?

  1. Single framework, project-tied — One framework runs against the project’s PED; outputs are deliverables for the user.
  2. Linear framework chain — Multiple frameworks run in sequence; output of each becomes input of the next.
  3. Corpus-mediated workflow (single corpus) — Multiple processes write to one corpus; multiple outputs render from it.
  4. Chained corpora — Multiple corpora connected by chain relationships (e.g., department-level → company-level).
  5. Mixed — Some single-framework work plus one or more corpus-mediated workflows.
  1. Confirm the pattern and record it. The pattern determines which Layer 3 elicitation branch runs.

OS-Modify: Change classification

  1. Read the user’s change description. Classify it:

    • Edit: Modifying existing rules — changing trigger lists, adjusting cadences, updating cross-section rules, refining escalation contacts, etc.
    • Expand: Adding new components — a new PFF writing to a new section, a new OFF reading from existing sections, a new corpus chained from an existing one, a new framework added to the chain.
    • Mixed: Both an edit and an expand. Process as an expand (the bigger change) with edits applied as part of the same invocation.

  2. Confirm the classification with the user before proceeding. Misclassifying expand as edit causes cascading effects to be missed.

  3. Identify which artifacts the change affects: PED only, corpus template only, workflow spec only, or multiple. Record affected artifacts.

OS-Verify: Verification scope identification

  1. Confirm the verification scope (project-level, workflow-level, or full). Default is full.

  2. For full, the verification covers PED + corpus template + workflow spec. For project-level, only PED. For workflow-level, only corpus template and workflow spec. For projects without workflow-level artifacts, full collapses to project-level.

  3. Record the scope; Layer 3 (verification mode) loads the appropriate check list.

Invariant check: Before proceeding to Layer 3, confirm that pattern (OS-Setup) / change classification (OS-Modify) / verification scope (OS-Verify) is recorded with rationale.

LAYER 3: DETAIL ELICITATION OR VERIFICATION

Role Shift: As the Progressive Questioner (OS-Setup, OS-Modify) or Comprehensive Verifier (OS-Verify), your focus is on extracting or checking the operational detail that produces (or validates) a complete configuration.

Stage Focus: Pattern-specific elicitation (OS-Setup), change-specific elicitation (OS-Modify), or comprehensive checks (OS-Verify).

Input: Pattern / change classification / scope from Layer 2.

Output: Elicited detail or check results.

Processing Instructions

OS-Setup: Pattern-specific elicitation

The questioning branches by pattern. In all branches, the framework asks one question at a time, waits for the answer, branches on the answer.

Branch 1: Single framework, project-tied.

  • Which framework? (Search framework registry; suggest matches.)
  • Which Active milestone(s) of the PED is the framework producing? (Match to existing milestones.)
  • Default trigger set: framework_started, milestone_complete, framework_complete, milestone_claimed, milestone_blocked, redefinition_evidence. Confirm with user; allow scoping.

Branch 2: Linear framework chain.

  • Which frameworks, in what order? (Walk through registry; user picks each in sequence.)
  • For each framework, which milestone(s) of the PED is it producing?
  • For each handoff (Framework A → Framework B), confirm the output contract of A matches the input contract of B (Layer 5 will verify).
  • Default trigger set as Branch 1. Confirm with user.

Branch 3: Corpus-mediated workflow (single corpus).

  • Does the corpus template exist already, or does it need to be designed?
    • IF needs designing → invoke CFF C-Design as a sub-task. CFF C-Design’s output (corpus template + workflow spec) becomes input here.
    • IF exists → confirm path; load.
  • Which PFFs write to the corpus? For each: confirm the section it writes to. (Match against corpus template’s sections.)
  • Which OFFs read from the corpus? For each: confirm the sections it reads.
  • Default trigger set as Branch 1 plus corpus events. Confirm.

Branch 4: Chained corpora.

  • What’s the chain topology? (Linear / tree / inverted-tree / DAG.)
  • For each corpus in the topology: existence check, design via CFF if needed, identify PFFs and OFFs.
  • For each chain relationship: source, dependent, propagation rule (re_validate / re_instantiate / no-op), trigger condition (section_updated / instance_recreated / template_version_changed).
  • Default trigger set as Branch 3.

Branch 5: Mixed.

  • Walk through Branch 1 or 2 for the project-level work.
  • Then walk through Branch 3 or 4 for each corpus-mediated workflow component.

OS-Modify: Change-specific elicitation

For edit changes:

  • Identify the specific rule being changed.
  • Confirm the new value.
  • Identify which artifacts carry the rule (typically one; cross-cutting rules may live in two).

For expand changes:

  • Identify what’s being added (new PFF / new OFF / new corpus / new chain link / new framework in chain).
  • Walk through the relevant Branch from OS-Setup’s pattern-specific elicitation, scoped to just the new component.
  • Identify cascading effects on existing components (e.g., new section requires downstream OFF compatibility check). Each cascading effect generates an additional change item that’s tracked alongside the primary change.

OS-Verify: Comprehensive checks

Run each of the following checks. Record each result.

  1. Artifact existence check. PED present at expected path? Corpus template present (if declared)? Workflow spec present (if declared)? Each PFF file present (per workflow spec)? Each OFF file present?

  2. Lock-readability check. PED’s Mission / Excluded Outcomes / Constraints parseable? Corpus template’s section specs parseable? Workflow spec’s chain rules and oversight rules parseable?

  3. Routing coverage check. Every event type declared in triggers_active has a routing-table entry? Every routing entry resolves to a callable handler? (Even if the handler isn’t running yet, the path must resolve.)

  4. Reference integrity check. Every referenced section exists in the corpus template? Every PFF references a section that exists? Every OFF references sections that exist? Every chain rule references a corpus that exists?

  5. Schema check. Each section’s declared schema is a parseable specification? Each cross-section rule references sections that exist?

  6. Synthetic event dry-run. Generate a test event of each declared type. Run each through the routing table. Confirm each produces the expected route + verdict (without actually modifying state — bypass verdict actions).

  7. Watcher heartbeat check. All required watchers running? Heartbeats fresh (within heartbeat interval)? Note: if no watchers are running yet (early implementation), record this as a known gap not a failure.

Invariant check: Before proceeding to Layer 4, confirm that elicitation (OS-Setup, OS-Modify) is complete or all checks (OS-Verify) have been run with results recorded.

LAYER 4: CROSS-CUTTING CONCERNS

Role Shift: As the Cross-Cutting Concerns Inquirer (OS-Setup, OS-Modify) or Dry-Run Conductor (OS-Verify), your focus is on the rules that span pattern-specific concerns: triggers, escalation, cadence coordination, and (for OS-Verify) the synthetic event dry-run.

Stage Focus: Trigger configuration, escalation, cadence coordination (OS-Setup, OS-Modify); synthetic event dry-run (OS-Verify, executed in Layer 3 step 6 — Layer 4 here is dry-run interpretation).

Input: Layer 3 output.

Output: Cross-cutting concerns elicited or dry-run analysis complete.

Processing Instructions

OS-Setup, OS-Modify: Cross-cutting concerns

  1. Trigger configuration. For each event type in the default set, ask whether it should fire oversight for this project. Default: all active. The user can exclude specific events with rationale (e.g., “this project doesn’t use chained corpora, exclude chain_propagation_required”).

  2. Escalation contact. Default: project owner (the project’s nexus owner). User can override per project, and per workflow within a project (workflow-level escalation overrides for chain-propagation events, etc.).

  3. Cadence coordination (Shape 4 only). For workflows with cadence-sensitive sections, elicit cadence-coordination rules: which PFF runs first in a period, what stale thresholds apply to OFFs, etc.

  4. Revisit triggers (project-level). For Working Assumptions in the PED’s Constraints section, confirm or refine the revisit trigger conditions translated for the periodic revisit-trigger sweep.

OS-Verify: Dry-run analysis

  1. Review each synthetic event dry-run result from Layer 3 step 6.

  2. For each event:

    • Did it route to the expected handler? Yes / No / Skipped.
    • Did the routing produce a verdict? PROCEED / REVISE / ESCALATE / Error / Skipped.
    • Did any error fire during routing or verdict generation?

  3. Note any mismatches between expected and actual outcomes. Mismatches are gap candidates for the verdict synthesis in Layer 5.

Invariant check: Before proceeding to Layer 5, confirm that cross-cutting concerns are elicited (OS-Setup, OS-Modify) or dry-run analysis is complete (OS-Verify).

LAYER 5: SPECIFICATION PRODUCTION OR VALIDATION SYNTHESIS

Role Shift: As the Specification Writer (OS-Setup, OS-Modify) or Verdict Synthesizer (OS-Verify), your task is to produce the final artifact — the configuration or the verdict.

Stage Focus: Write specifications to artifacts (OS-Setup, OS-Modify); synthesize verification verdict (OS-Verify).

Input: Layers 3–4 output.

Output: Updated artifacts + Decision Log entries (OS-Setup, OS-Modify); verdict report (OS-Verify).

Processing Instructions

OS-Setup: Initial specification production

  1. Project-level Oversight Specification. Compose the YAML block per Reference — Meta-Layer Architecture §11. Insert into the PED under ## Oversight Specification. If a section by that name already exists (it shouldn’t, for OS-Setup), halt and surface the conflict.

  2. Section-level oversight rules (Shape 4 only). For each section in the corpus template, extend the existing section block with the oversight sub-block per §11. Preserve the corpus template’s existing fields.

  3. Cross-corpus topology rules (multi-framework only). Extend the workflow spec’s frontmatter with the oversight block per §11. Preserve the workflow spec’s existing fields.

  4. Decision Log entry. Record the OC invocation in the PED’s Decision Log: mode (OS-Setup), pattern detected, key decisions (which frameworks, which corpora, which triggers), date.

  5. Iteration entry. Append an iteration entry to the PED noting that oversight has been configured.

OS-Modify: Update specification

  1. Apply each change identified in Layer 3 to the appropriate artifact. Edits modify existing fields; expansions add new fields.

  2. For each change, append a Decision Log entry citing the change description and the rationale.

  3. For cascading effects identified in Layer 3, apply each as part of the same update transaction. Either all changes land together or none do (file lock primitive ensures atomicity).

  4. Iteration entry as in OS-Setup.

OS-Verify: Verdict synthesis

  1. Review all check results from Layer 3 and dry-run analysis from Layer 4.

  2. Determine the verdict:

    • READY when: all checks passed; all dry-runs produced expected verdicts; all watchers (if running) heartbeat fresh.
    • READY-WITH-WARNINGS when: all checks passed but some non-blocking issues exist (e.g., a watcher isn’t running yet but the configuration is correct; a stale-but-non-critical reference).
    • NOT-READY when: one or more checks failed; one or more dry-runs produced errors or wrong-routing; required artifacts are missing.

  3. Compose the verification report: verdict, per-check status, per-event dry-run status, gap list (if not READY).

  4. For NOT-READY, compose an OS-Modify Handoff Package: pre-populated change description listing the specific gaps to address, with recommended resolution per gap.

Invariant check: Before proceeding to Layer 6, confirm that artifacts are updated (OS-Setup, OS-Modify) with corresponding Decision Log entries, or that the verdict is composed with full evidence (OS-Verify).

LAYER 6: HANDOFF AND NOTIFICATION

Role Shift: As the Handoff Producer, your task is to package the output for downstream consumption.

Stage Focus: Produce the OS-Verify Handoff Package (OS-Setup, OS-Modify) or the OS-Modify Handoff Package (OS-Verify NOT-READY).

Input: Layer 5 output.

Output: Handoff package(s) and user-facing summary.

Processing Instructions

OS-Setup, OS-Modify: OS-Verify Handoff

  1. Bundle the updated artifacts (paths + content references) into a structured handoff that OS-Verify can consume without re-loading.

  2. Surface a brief user-facing summary: “Configuration written. Project [name] now has oversight at [project-level / project + workflow]. Next: OS-Verify will dry-run the configuration.”

  3. Recommend OS-Verify execution. The user can run it now or defer.

OS-Verify: Conditional Handoff

  1. IF verdict is READY: surface the verification report. No handoff package; the configuration is in production-ready state.

  2. IF verdict is READY-WITH-WARNINGS: surface the report with warnings highlighted. No automatic handoff; the user can choose to proceed or address warnings.

  3. IF verdict is NOT-READY: surface the report with the gap list. Produce the OS-Modify Handoff Package with pre-populated change description. Recommend OS-Modify execution.

Invariant check: Before proceeding to Layer 7, confirm that handoff is produced (or skipped with rationale) and the user-facing summary accurately reflects the framework’s output.

LAYER 7: SELF-EVALUATION

Stage Focus: Evaluate this framework’s output against the 6 Evaluation Criteria.

Calibration warning: Self-evaluation scores are systematically inflated. Score conservatively; articulate uncertainties alongside scores.

Processing Instructions

For each criterion:

  1. State the criterion name and number.
  2. Verify the current output against the criterion’s rubric descriptions before scoring.
  3. Identify specific evidence supporting or undermining each score level.
  4. Assign a score (1-5) with cited evidence.
  5. IF score is below 3, identify the deficiency, state the modification required, apply it, re-score.
  6. IF score meets or exceeds 3, confirm and proceed.

After all criteria are evaluated:

  • IF all scores meet threshold, proceed to Layer 8.
  • IF any score remains below threshold after one modification attempt, flag with UNRESOLVED DEFICIENCY label and state what additional input would resolve it.

LAYER 8: ERROR CORRECTION AND OUTPUT FORMATTING

Stage Focus: Final verification, mechanical error correction, output formatting.

Error Correction Protocol

  1. Verify that every artifact updated by this invocation has been actually written (not just composed) and the file-lock primitive was acquired and released.
  2. Verify that Decision Log entries were appended to the PED for every substantive change.
  3. Verify that the iteration entry was appended.
  4. Verify cross-artifact consistency: section names match across corpus template and workflow spec; chain references resolve; trigger declarations align.
  5. Verify the handoff package includes all expected fields.
  6. For OS-Verify: verify that the verdict matches the evidence.
  7. Document all corrections in a Corrections Log appended to the output.

Output Formatting

Present the complete output in this order:

  1. Mode (from Layer 1)
  2. Pattern / change classification / verification scope (from Layer 2)
  3. Elicited rules / change details / check results (from Layer 3)
  4. Cross-cutting concerns / dry-run analysis (from Layer 4)
  5. Updated artifacts (paths + change summary) / verification report (from Layer 5)
  6. Handoff package (from Layer 6)
  7. Self-Evaluation Summary (from Layer 7)
  8. Corrections Log (from this layer)

Missing Information Declaration

Before finalizing, state:

  • Any input information expected but absent.
  • Any layer where insufficient information forced assumptions.
  • Any criterion where score reflects gap in available information rather than quality.

NAMED FAILURE MODES

1. The Default Acceptance Trap

What goes wrong: The user accepts every default offered without consideration, producing a configuration that’s nominally complete but doesn’t reflect their actual project structure. The configuration passes OS-Verify but fails when real events arrive because the rules don’t match the work.

Correction: Layer 3 elicitation requires the user to confirm or refine each rule; Layer 7 criterion 2 (Progressive Questioning Quality) penalizes passive acceptance of defaults that the framework should have flagged for refinement.

2. The Pattern Misclassification Trap (OS-Setup)

What goes wrong: The framework classifies the work as Shape 3 (direct PFF→OFF) when it’s actually Shape 4 (corpus-mediated). The configuration writes a linear-chain spec instead of a corpus-mediated spec, and the workflow can’t grow without redesign.

Correction: Layer 2 step 2 explicitly asks the high-level pattern question. The user’s answer is recorded; if the framework infers a pattern from PED clues, the inference is presented as a hypothesis the user confirms before proceeding. The Belated Corpus Trap from the PFF-CFF-OFF integration architecture is the failure this addresses.

3. The Cascading Effects Blindness Trap (OS-Modify)

What goes wrong: The user requests a small change (add a new PFF), but the change has cascading effects (the new PFF requires a new section, which requires updating downstream OFFs to handle the new section). The framework applies only the requested change and silently leaves the cascading effects unaddressed.

Correction: Layer 3 OS-Modify branch explicitly identifies cascading effects and tracks them as additional change items. Layer 7 criterion 5 (Cascading Effects Surfaced) penalizes failure to identify and address cascading effects.

4. The Verification Theater Trap (OS-Verify)

What goes wrong: The framework reports READY without actually running every declared check — checks are listed in the report but not executed, or executed superficially.

Correction: Layer 3 OS-Verify branch requires that every check declared be actually run, with each result recorded. Layer 7 criterion 1 (Check Coverage) penalizes skipped checks. Layer 8 step 6 verifies that the verdict matches the evidence.

5. The Cross-Artifact Inconsistency Trap (OS-Setup, OS-Modify)

What goes wrong: The framework updates the PED but forgets to update the corpus template, or updates the workflow spec but the corpus template still references old section names. The artifacts diverge silently.

Correction: Layer 5 specification production uses a single transaction-style write across artifacts (file lock primitive ensures atomicity). Layer 8 step 4 explicitly verifies cross-artifact consistency. Layer 7 criterion 4 (Cross-Artifact Consistency) penalizes inconsistencies.

6. The CFF Pass-Through Trap

What goes wrong: OS-Setup is invoked with Shape 4 pattern but the corpus template needs designing. The framework attempts to elicit corpus structure inline rather than handing off to CFF C-Design. The resulting corpus template is incomplete.

Correction: Layer 3 Branch 3 step 1 explicitly invokes CFF C-Design as a sub-task when the corpus template doesn’t exist. The framework does not invent corpus structure — that’s CFF’s job; the framework only elicits the oversight rules that go on top of a CFF-designed corpus.

7. The Verbose Questioning Trap

What goes wrong: Layer 3 elicitation asks too many questions, including ones the user has already answered or ones the answer to a prior question made irrelevant. The user disengages before the configuration is complete.

Correction: Each Layer 3 question is contingent on prior answers. The framework tracks what’s been confirmed and skips redundant questions. Layer 7 criterion 2 (Progressive Questioning Quality) penalizes interrogative questioning.

8. The Stale-Reference Verification Trap (OS-Verify)

What goes wrong: OS-Verify reports a stale reference (a renamed file, a moved directory) but the verdict is READY because the framework couldn’t determine whether the stale reference is significant. The configuration runs in production and fails on the stale reference.

Correction: Stale references are always at minimum READY-WITH-WARNINGS. NOT-READY when the stale reference is in a path that the routing depends on (e.g., a missing PFF file referenced in the workflow spec). The framework errs on the side of surfacing rather than suppressing.

EXECUTION COMMANDS

  1. Confirm you have fully processed this framework and the input materials.
  2. Identify the operating mode (Layer 1).
  3. IF mode is ambiguous, ask the user to confirm before proceeding.
  4. IF any required inputs are missing, list them and request before proceeding.
  5. IF any required inputs are present but ambiguous, state what you understand and what you’re uncertain about. Wait for confirmation before proceeding.
  6. Execute the appropriate layer sequence per the Milestones Delivered section.
  7. Apply Self-Evaluation (Layer 7) and Error Correction (Layer 8) before delivery.
  8. Present outputs per Layer 8’s Output Formatting.

USER INPUT

[State Mode (OS-Setup / OS-Modify / OS-Verify) — or let the AI auto-detect from context. Then provide the project nexus or PED path. For OS-Modify, also provide the change description. For OS-Verify, optionally provide the verification scope.]

END OF OVERSIGHT CONFIGURATION FRAMEWORK v1.1