/oracle-pre-query — Structured Pre-Check for Oracle Queries

An "oracle" here means a NotebookLM notebook (or similar tool) built from a person's own material — their past conversations, corrections, and principles — that agents query to predict how that person would react to a piece of work. This is optional infrastructure: it needs the person's own history loaded into their own notebook. If you haven't set one up yet, skip to No Oracle Configured below — the framing discipline in this file is still worth doing even with nothing to send it to.

Why This Exists

An oracle built from someone's history answers from whatever it knows best. If most of what's in it is product/UX conversations, then a question about agent infrastructure, data pipelines, or other plumbing work will come back full of product advice that doesn't apply — confidently, and wrong for the domain.

Example of the failure this guards against (illustrative): one person-prediction oracle, trained on thousands of a person's own conversations, was predominantly product-UX work. An early oracle query about agent-infrastructure hooks came back 50% misapplied product patterns (simulator URLs, unit-economics framing, customer-facing UX) because the query didn't frame the domain. Adding this structured pre-check reduced misapplication to roughly 11% on a later sample. That's one measurement from one incident on one oracle — a reason to keep the discipline, not a number to promise as your own result.

When to Use

Every time you call a person-prediction oracle (jonathan-check2, jonathan-check3, or whatever you've set up as your own version). No exceptions — if you notice yourself skipping this because it feels like overhead on a small question, that's exactly the case this file exists to cover.

No Oracle Configured

If you haven't set up an oracle yet:

1. Say so plainly: "Before I'd ask a memory notebook how you'd react to this, I first write down what the work is and isn't — otherwise the notebook answers from whatever it knows best, which might be the wrong domain. You don't have an oracle set up yet, so there's nothing to send this to."
2. Still run Step 1 (reflect) and Step 2 (the schema below) and print them — the framing discipline is useful on its own, independent of whether anything answers it.
3. In place of an oracle answer, reason from what you actually have: the person's own repo docs, git log (especially messages and diffs where they corrected a prior agent), and their past Claude Code sessions under ~/.claude/projects/*/*.jsonl (grep for relevant topics and their own corrections). This is a real substitute for institutional memory, not a guess dressed up as one — but say plainly that it's a search of what's on hand, not a prediction backed by an oracle.
4. Offer to walk through setting up an oracle via /alignment-harness:harness-setup (checkpoint: oracles) if they want the fuller cycle.
5. Never present a guess as if it were an oracle's prediction.

Oracle Selection — Which Oracle for Which Question

If you have more than one oracle set up, you may query multiple. The pre-query schema (Step 2) determines which ones. Print ALL queries and ALL responses.

Routing table — build your own

The mechanism is: route each domain to whichever of your own notebooks covers it, and keep a domain-agnostic, principles-based notebook (if you have one) as the default when you're unsure. A minimal version needs only one notebook — everything routes to it. As you build more, a routing table like this keeps each domain going to the notebook that actually knows it:

Domain	Route to
product-ux	your broadest/default notebook
agent-infrastructure	a principles notebook first, then your default — architecture questions confuse a product-heavy notebook
data-pipeline	same as agent-infrastructure
business-strategy	a unit-economics notebook (if you have one) plus your default
content	your default (voice/tone patterns usually live there)
which-skill-to-use	a skill-registry notebook, if you have one — the others won't have that coverage
other	your principles notebook first, then route once it tells you the actual domain

Keep the config for this — which notebook ID maps to which domain, and an on/off switch per notebook — in whatever local config /alignment-harness:harness-setup walks you through, not hardcoded in this file.

Example of a working routing table (illustrative — replace with your own notebooks, never reuse these): one setup sends agent-infrastructure questions to a principles notebook plus a person-predictor oracle; business/revenue questions to a unit-economics notebook plus the person-predictor; skill-sequencing questions to a small skill-pattern notebook alone; and architecture questions to an agent-firm-design notebook plus the principles notebook, deliberately skipping the person-predictor because it defaults to product patterns for architecture questions. These are one person's notebooks, built from their own history — a new person's routing table should have their own domains and their own notebooks in these slots, not these names.

Selection Rules

• Default (uncertain): query your principles/domain-agnostic notebook first, if you have one — it will tell you which notebook actually applies.
• Agent infrastructure: principles notebook AND person-predictor, if both exist — principles catches value/principle violations, the person-predictor catches personal-preference gaps.
• Business/revenue decisions: a unit-economics notebook AND the person-predictor, if both exist.
• Skill sequencing: a skill-registry notebook alone, if you have one — the others won't have that coverage.
• Agent system architecture: a principles/architecture notebook, not the person-predictor — it defaults to product-UX patterns for architecture questions.

---

Step 1: Run /reflect on the SCOPE

Before answering the schema, run /reflect on what you're about to ask the oracle to evaluate. The reflection must be about the SCOPE — not about the process of querying the oracle. Do not inject hints about what the oracle should or shouldn't say.

Step 2: Answer the Pre-Query Schema

oracle_pre_query:
  domain: "[product-ux | agent-infrastructure | data-pipeline | business-strategy | content | other: ___]"
  audience: "Who experiences the result of this work?"
  success_looks_like: "One sentence — what does 'working' look like to that audience?"
  perfect_looks_like: "What does 10/10 realization look like? Nuance proportional to task complexity AND gravity."
  does_not_touch: "Explicit list of what this work does NOT affect"
  failure_modes: "The specific failures being designed against"
  similar_past_work: "Prior sessions or patterns this resembles"
  intent_declaration: "Robust intent statement — nuanced relative to complexity AND gravity of the task"

Step 3: Compose the Oracle Query

Include the schema output as PREAMBLE to your oracle query. The schema fields become the first section of the query, followed by whatever you're asking the oracle to evaluate.

Step 4: Print EVERYTHING

Print the FULL query verbatim to the conversation BEFORE sending it. Print the FULL response verbatim AFTER receiving it. Never summarize oracle interactions. The person must be able to see exactly what was asked and exactly what came back.

Step 5: Tag Each Challenge

For each challenge the oracle raises:

• DOMAIN-RELEVANT: references agent behavior, hook correctness, skill file quality, session state, or whatever domain you declared
• POTENTIALLY-MISAPPLIED: references patterns from a different domain than what you declared

Step 6: Handle Disagreement (Governer-Gated)

If the agent disagrees with the oracle AND the task's /governer score is high enough:

1. Round 1: Send a correction query: "You raised [challenge]. This work is in [domain] and does not touch [boundary]. Given that constraint, what [domain]-specific challenge would you raise instead?"
2. Round 2: If oracle maintains its position, send one more clarification with specific evidence
3. After 2 rounds: If still disagreeing, escalate to the /orchestrator skill if you're running under it (it reads both positions plus evidence and makes the call, logged with reasoning). If you're not running an orchestrator — most single-session interactive work — the agent makes the call directly, states its reasoning and confidence explicitly (not as certainty), and surfaces the unresolved disagreement to the person rather than silently picking a side.

If the task's /governer score is LOW (below the threshold for human review), the agent makes the call directly and logs the reasoning either way.

What Bad Looks Like

• Sending an oracle query without running this protocol first
• Running /reflect on "how to query the oracle" instead of on the actual scope
• Injecting the answers into the reflection (cheating the test — the reflection must derive domain context naturally)
• Summarizing the oracle response instead of printing it verbatim
• Accepting all oracle challenges without tagging domain relevance
• In a solo session with no orchestrator, quietly picking a side on an unresolved disagreement instead of surfacing it to the person
• Presenting a no-oracle-configured guess as if an oracle had predicted it