Current phase: references + governance + API enforcement

How OiMy will use “frontier quality” during inference

Simple version: GPT‑5.5 and Opus help us design what excellent looks like offline. At runtime, the app should not blindly trust a model. It routes the user request through skills, memory, tools, and deterministic safety/governance gates before returning an answer.

83/83skills have reference specs
28/28runtime governance gates pass
2×frontier models cross-review
~$4.40estimated spend so far

1) The key idea

Before

User asks → model/skill replies. If the skill is shallow, it may give generic advice, fake tool actions, forget constraints, or miss safety issues.

Risk: “I booked it / called them / checked traffic” even when no tool actually did that.

Now / target

User asks → route skill → load memory → create draft/plan → governance checks facts, assumptions, missing confirmations, live data, side effects, privacy, and safety.

Outcome: helpful answer, but with guardrails: no fake sends, no unverified live data, no unsafe child/health/elder assumptions.

2) Runtime flow during inference

This is what should happen every time a user sends a message.

1

User input

“Set up soccer carpool Tue/Thu…”

2

Route skill

Router chooses carpool/planner, or safety override if emergency.

3

Load memory

Kids, preferences, past plans, constraints, permissions.

4

Skill logic

Builds draft plan using rule packs and skill references.

5

Governance

Checks missing confirmations, live data, side effects, safety, privacy.

6

Block/downgrade

If unsafe: draft only, ask confirmation, or emergency guidance.

7

Respond

Returns answer + hidden/structured governance envelope.

3) What the governance envelope does

Reliability contract

Every response carries facts, assumptions, missing confirmations, unsafe unknowns, side effects, plan status, freshness.

draftneeds_confirmationblocked

Side-effect ledger

Before sending/bookings/orders/calendar writes, OiMy must create a proposed action, get confirmation, then require a tool receipt.

proposedconfirmedexecuted

Claim binding

If the response says weather/traffic/price/hours, it needs a fresh source receipt — otherwise it must say “not connected / verify.”

weather receipttraffic receipt

4) Practical example: carpool

User: Set up a Tue/Thu soccer carpool for Ava, Ben, and Chloe. Parents are me, Sam, and Priya. Practice is 5pm across town.

Good answer: Draft rotation, leave-time buffer, booster/car-seat confirmation, exact pickup spot, authorized adults, backup driver, late protocol, carpool kit, draft message to parents.

Governance blocks: It cannot say “I texted Sam” unless SMS capability exists, user confirmed exact message/recipients, and a tool receipt is logged. It cannot claim live traffic unless traffic integration returns a fresh receipt.

5) Why two frontier models?

GPT‑5.5

Generated references, reviewed Opus-driven fixes, found bypasses like negation and fake ledger binding.

↔

Opus 4.7

Reviewed GPT outputs, forced deterministic gates, then passed final governance/API integration after fixes.

6) What is done vs left

Done

  • 83/83 skill references generated.
  • Cross-model review loop established.
  • Runtime governance primitives added.
  • API governance envelope added.
  • E2E governance eval passes.

Left

  • Convert references into runtime behavior for all skills.
  • Make archetypes emit explicit reliability instead of wrapper inference.
  • Add broad golden evals for all skills and failure modes.
  • Wire real integrations through side-effect ledger.
  • Human review for emergency/health/minor safety packs.

7) Concrete next steps

  1. Batch 1: Make all action skills use the side-effect ledger and confirmation engine.
  2. Batch 2: Make planner skills emit explicit reliability contracts and rule-pack validation.
  3. Batch 3: Expand coach/expert safety gates and human-review-ready safety packs.
  4. Batch 4: Build 83-skill golden eval suite from the references.
  5. Batch 5: Deploy/restart, run live endpoint QA, then prepare production test plan.

8) Mental model

Frontier models = architects and reviewers Runtime skills = deterministic operators Governance = seatbelt + audit trail Side-effect ledger = proof before saying “done” Golden references = what excellent should look like Evals = proof we stayed excellent after code changes
Generated for OiMy IP-quality phase — cross-reviewed governance foundation, May 2026