Premise review

Premise Review

Overview

Review the frame outside the loop that optimizes against it. Use a fixed trigger, a named owner outside routine execution, and a durable record so good-looking output cannot cancel the review.

When to use

• At a fixed calendar, session-count, or milestone trigger.
• Before scaling a recurring workflow or after a long period without frame review.
• When thresholds, rules, memory, gates, or readiness evidence may be stale.

When NOT to use: as a reaction to one bad output (use review-gate); during a freshly confirmed frame; or to silently rewrite standing instructions.

Process

1. Confirm trigger and owner. Record the output-independent trigger, the reviewer outside routine execution, the review date, and the next due date.
2. Commit staleness criteria before recent results. State what would make a premise stale or unreviewable; do not tailor criteria to preserve the status quo.
3. Inventory premises in assets/premise-register.md:
   • goals, target values, criteria, thresholds, and escalation rules;
   • workflow-readiness evidence, task-specific reliability, intervention design, and architecture/resilience assumptions;
   • deterministic-versus-agentic routing, the final mode of each step, both gates, blast-radius boundaries, and friction requirements;
   • standing rules, persistent memory, roles, and review cadence.
4. Evaluate each premise. Record when it was last verified, what changed, the current evidence, and one verdict: confirmed, stale, or unreviewed.
5. Expose excluded alternatives. Name at least one plausible goal, metric, criterion, interpretation, or routing option hidden by the current frame.
6. Re-run affected stages. If readiness evidence or workflow boundaries changed, propose a new workflow-readiness screen. If dimensions, gates, or constraints changed, propose a new task-profile.
7. Propose, do not apply. Present each threshold, rule, memory, routing, mode, or cadence change with rationale and consequences. Wait for a human decision before persistence or deletion.
8. Document the outcome. Record decisions, unresolved items, owner, and next trigger. Required review cannot be disabled through a friction off setting.

Rationalizations

Excuse	Rebuttal
"Results are good, so the frame is fine."	Results only show performance against the current frame.
"We can fold this into output review."	Output and premise review answer different questions and use different triggers.
"The reliability evidence is probably still representative."	Record its scope and date; otherwise mark it unreviewed.
"This memory change is too small for approval."	Persistent assumptions steer future sessions and remain governed.

Red flags

• Review timing depends on whether output looks successful.
• No named owner outside routine workflow execution.
• Readiness, routing, or gate assumptions omitted from the register.
• unreviewed silently converted to confirmed.
• Proposed memory or rule changes applied without human approval.

Verification

The review is complete when trigger, owner, criteria, and dates are recorded; every in-scope premise has evidence and a dated verdict; an excluded alternative is visible; changed premises route back to the correct framework stage; every persistent change has a human decision; and the next review is scheduled.