• 

ScopePatch

One correction. The right lesson. The right scope.

Inspiration

Persistent agents need to learn from human feedback, but learning creates a new kind of risk.

If an agent ignores a correction, it repeats the same mistake. If it learns too broadly, one local edit can silently change unrelated future behavior. For example, when a meal planner schedules a 45-minute salmon dinner after the user arrives home at 8:30 PM, replacing it with a quick meal does not necessarily mean “never cook salmon” or “always choose noodles.” The intended lesson may simply be: after a late arrival, choose a meal that takes no more than 15 minutes to prepare.

Most memory systems focus on whether feedback is remembered. We wanted to focus on whether the agent learned the correct abstraction, applied it at the right scope, and proved that unrelated behavior remained protected.

That idea became ScopePatch: a governance layer for safe, testable agent learning.

What it does

ScopePatch converts a human correction into a scoped, regression-tested, human-approved behavior patch.

The reference application is a weekly Meal Planner. It intentionally produces a valid but unrealistic plan: a long dinner on a night when the user gets home late. After the user replaces the meal, ScopePatch:

1. Stores the original run, correction, and active policy version as separate evidence.
2. Considers multiple explanations for why the user made the edit.
3. Asks one counterfactual question to distinguish a conditional rule from a global preference or one-time request.
4. Proposes the smallest supported policy change.
5. Runs positive, negative, boundary, and historical regression cases against the candidate policy.
6. Validates deterministic constraints such as budget, ingredient expiry, calendar conflicts, patch paths, and policy versions.
7. Requires explicit human approval before persistence.
8. Creates a new immutable policy version with audit history and rollback support.

The model can propose a lesson, but it cannot approve or directly persist one.

After the rule is approved, a four-week replay demonstrates that the agent learned transferable knowledge rather than memorizing a menu. The learned rule activates once, once, twice, and then zero times as arrival times and meal options change. Different late nights receive different quick meals, expiring ingredients are rescheduled safely, and 18 unrelated meals remain unchanged.

ScopePatch also demonstrates a controlled lifecycle:

add rule → refine rule → use once → rollback

A one-time correction does not create a policy version, and rollback does not erase history. Restoring an earlier policy creates a new version while previous versions remain auditable.

How we built it

ScopePatch is built with Next.js/Vinext and TypeScript. Its reusable, domain-independent engine lives separately from the Meal Planner reference application.

The core architecture includes:

• Zod schemas for all model-generated and persisted data
• An explicit patch state machine
• Allow-listed JSON policy operations
• Engine-owned IDs and base versions
• A shared candidate-policy executor used for both evaluation and production behavior
• Deterministic domain validation
• SQLite persistence for local development
• Immutable policy versions and append-only audit events
• Optimistic version checks and stale-patch blocking
• Rollback implemented as a new version rather than destructive history rewriting

Codex with GPT-5.6 was our development partner throughout the project. It helped translate the product requirements into architecture, implement the governed patch lifecycle, design bidirectional evaluations, reproduce version conflicts, perform visual browser QA, prepare deployment, and create the submission workflow.

Codex also helped uncover problems that were difficult to see in a single golden-path test. One example was a multi-round question-ID collision that could cause evidence from one correction to overwrite another. The final engine replaces provider-generated identities and base versions with engine-owned values before evaluation or persistence.

The project includes an optional OpenAI Responses API provider for structured correction hypotheses, counterfactual questions, patch proposals, and evaluation candidates. The public Judge Mode uses deterministic structured proposals, allowing judges to test the complete governance workflow without registering for an API key. The engine still performs validation, evaluation, approval, versioning, and audit enforcement.

Challenges we faced

Learning the right abstraction

The hardest challenge was demonstrating that learning meant a reusable behavior change rather than a hard-coded meal replacement.

We addressed this by comparing execution under the previous and candidate policies, testing both target and protected scenarios, and replaying the learned rule across changing future-week inputs.

Keeping model assistance separate from authority

Model inference is useful for proposing explanations and candidate changes, but it should not be trusted as the final authority over persistent behavior.

ScopePatch therefore treats every model response as untrusted proposal data. Schema validation, semantic checks, IDs, policy versions, deterministic evaluation, approval, persistence, audit, and rollback remain under engine control.

Preventing stale updates

A patch must merge against the same policy version on which it was evaluated. If the active version changes, ScopePatch blocks the stale patch and requires re-evaluation instead of silently applying it to a different policy.

Preserving behavior across multiple learning rounds

Several identity and versioning bugs only appeared when corrections were added, refined, used once, and rolled back in sequence. This led us to build multi-round lifecycle tests rather than relying only on one successful demonstration.

Accomplishments

We completed:

• A full correction-to-learning workflow
• Scoped clarification through a counterfactual question
• Positive and protected-behavior regression evaluation
• Explicit human approval before persistence
• Immutable versions, audit history, and rollback
• Stale-version conflict detection and re-evaluation
• One-time corrections that do not modify policy
• Four-week continuous-learning evidence
• 28 automated core and service tests
• Production build, rendered-page, browser, and HTTP verification
• A public repository with an MIT license and complete setup instructions

What we learned

Agent feedback requires two boundaries.

The first is an abstraction boundary between task data and reusable policy. A changed answer is evidence, but it is not automatically a general rule.

The second is an authority boundary between model inference and persistent state. A model can suggest what should be learned, but validation, evaluation, approval, and persistence must remain governed.

We also learned that negative and historical evaluations are as important as the target success case. It is not enough to prove that the corrected scenario works; a safe learning system must prove that unrelated behavior did not change.

Finally, multi-round testing is essential. Many lifecycle, identity, and versioning failures remain invisible in a single successful demonstration.

What's next

Next, we would extract the ScopePatch engine into a documented adapter SDK, add pluggable policy stores and evaluation runners, and support team approval policies.

We also want to demonstrate the same governed-learning workflow in other domains, such as coding agents, customer-support agents, and internal business automations.

The core principle will remain unchanged:

No persistent behavior change without scoped evidence, deterministic checks, explicit human authority, immutable history, and rollback.

Built With

• api
• cloudflare
• codex
• gpt-5.6
• next.js
• node.js
• react
• responses
• sqlite
• typescript
• vinext
• vite
• workers
• zod