🤖 machine learning

PatchOptic for Shared-State LLM Workflows with Projected Views and Verified Structured Updates

This paper introduces PatchOptic, an optic-inspired interface for shared-state LLM workflows that ensures global validity of local updates through projected reads and verified structured patches, while enabling static guarantees for workflow composition and reducing token costs without compromising output quality.

Original authors: Zhaoyu Bai, Jiaqi Cai

Published 2026-07-08

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Zhaoyu Bai, Jiaqi Cai

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are the manager of a massive, shared digital library. This library holds everything: secret blueprints, private user files, financial records, and public news. You hire a team of very smart, but sometimes distracted or mischievous, AI assistants (the "actors") to help you organize this library.

The problem is that the library is too big for any single assistant to see all at once. If you show them the whole library, they might accidentally (or on purpose) leak a secret blueprint into a public report. If you only show them a small page, they might try to move a book to a shelf they aren't allowed to touch, or they might try to copy a secret page into their report without you realizing it.

PatchOptic is a new system designed to solve this mess. It acts like a strict, invisible security guard and a smart librarian rolled into one. Here is how it works, using simple analogies:

1. The "Projector" (Projected Reads)

Imagine you have a projector that shines a light on only the specific page of the library book the assistant needs to work on right now.

Without PatchOptic: You hand the assistant the whole book. They might see a secret note in the margins and accidentally copy it into their summary.
With PatchOptic: The projector only shows the assistant the specific paragraph they need. The rest of the book is invisible to them. This is called Projected Read. It stops the assistant from even seeing the secrets, so they can't leak them. It also saves time (tokens) because the assistant doesn't have to read the whole book.

2. The "Security Guard" (Verified Structured Updates)

Once the assistant finishes their task, they don't just walk up to the bookshelf and start moving things around. Instead, they write a formal request on a special form (a "Patch").

The Request: The assistant says, "I want to move the book from Shelf A to Shelf B."
The Guard's Job: Before the book actually moves, a security guard (the Verifier) checks the request against the entire library's rules, not just what the assistant saw.
- Did they try to move a book to a forbidden shelf? (Write Scope Check)
- Did they try to move a book from a secret section they weren't allowed to touch? (Patch-Source Check)
- Is it the right time of day to move books? (Phase Check)
- Does the new arrangement break any library rules? (Invariant Check)

If the request breaks any rule, the guard says "No," and the book stays exactly where it was. The assistant never gets to touch the real library unless they pass every check.

3. The "Blueprint" (Footprints)

Before the assistants even start working, the system draws a "blueprint" (called a Footprint) for each task. This blueprint lists exactly:

What the assistant is allowed to read.
What they are allowed to write.
What they are allowed to copy from.

This blueprint allows the manager to do two cool things:

Delegation: If you want to hire a new, less experienced assistant, you can give them a "smaller" version of the blueprint. They can only do a tiny part of the job, and the system knows exactly what they can and can't touch.
Reordering: If two assistants are working on different parts of the library that don't overlap (like one is fixing the fiction section and the other is fixing the science section), the system knows they can work in any order without causing a mess. It's like knowing two painters can paint different walls at the same time without bumping into each other.

What the Paper Found

The authors tested this system (called PatchOptic) against a standard way of doing things using a test suite called PatchBench (46 different scenarios like finance, medical, and software tasks).

Here is what happened:

Less Leaking: When the assistants could only see the "projected" part of the library, they leaked secrets almost 100% less often than when they saw the whole thing.
Cheaper: Because they didn't have to read the whole library, the system used less computing power (fewer "tokens").
Better Safety: When the assistants tried to make illegal moves (like copying a secret file), the "Security Guard" caught them every time before the change happened.
Quality: The assistants still did their jobs well. They didn't get confused by seeing less; they just focused on what they were allowed to see.

The Bottom Line

PatchOptic is a way to let AI assistants work on big, shared databases without trusting them to be perfect. It says:

Show them only what they need (so they can't steal secrets).
Check their work against the whole system before letting them make changes (so they can't break rules).
Keep a written record of exactly what they were allowed to do (so you can audit them later).

It turns the risky job of "asking an AI to fix a shared database" into a safe, controlled process where the AI is the worker, but the system is the boss.

Technical Summary: PatchOptic for Shared-State LLM Workflows

Problem Statement

In agentic workflows operating over shared, structured state, a fundamental mismatch exists between the limited context windows of Large Language Models (LLMs) and the global validity requirements of the system. To manage context, systems employ progressive disclosure, exposing only the state fragment necessary for a specific step (e.g., via RAG or AST queries). While this manages the read side, the write side remains vulnerable.

When an agent proposes an update based solely on a local fragment, it lacks the global context required to validate the update against the full state. This leads to two primary failure families:

Secret Leakage: Protected values irrelevant to the current step enter the agent's view and are inadvertently disclosed in the output.
Commit-Legality Failures: Agents propose patches that are malformed, violate phase constraints, write outside authorized scopes, or derive values from unauthorized state paths (hidden sources).

Existing controls like schema validators or constrained decoding address local syntax or structure but fail to verify the provenance of state values or the global validity of a transition. There is a lack of a "contract" that connects local rewrites to global validity and composes across multi-step, multi-agent workflows.

Methodology: PatchOptic Design

The paper introduces PatchOptic, an optic-inspired interface that couples projected reads with verified structured updates. The core mechanism relies on a step contract defined by an authority triple $(O_s, W_s, P_s)$ :

$O_s$ (Projected Read): A projection of the full shared state $x$ into a local view $O_s(x)$ visible to the actor.
$W_s$ (Write Region): The set of state paths the actor is authorized to modify.
$P_s$ (Patch-Source Region): The set of current-state paths the actor is authorized to read during the application of the patch (e.g., for copy, move, or test operations in JSON Patch).

Runtime Enforcement

The runtime path operates as follows:

Projection: The actor receives only the projected view $O_s(x)$ , hiding sensitive fields.
Proposal: The actor generates a mutation proposal (implemented as a JSON Patch).
Verification: Before committing, a verifier checks the proposal against the full state $x$ $x$ using four gates:
- Scope: Ensures write targets and patch-source paths (including from paths for move) remain within $W_s$ and $P_s$ .
- Phase: Validates the step is allowed in the current workflow phase.
- Schema: Checks structural validity and output contracts.
- Invariants: Verifies workflow invariants hold post-mutation.
Commit/Reject: State mutates only if all gates pass; otherwise, the proposal is rejected, and the state remains unchanged.

Static Footprint Algebra

Beyond runtime, the step declaration yields a static footprint $(R_s, W_s, P_s)$ (where $R_s$ is the realized read region). This enables static analysis before actors run:

Restriction: Supports delegation by narrowing footprints for sub-actors.
Union: Supports peer composition by combining footprints.
Commutation Certificate: Allows safe reordering of independent steps within the same phase. Two steps can be reordered if their write regions are disjoint and neither reads what the other writes ( $W_A \perp W_B$ , $R_A \perp W_B$ , $R_B \perp W_A$ ).

Key Contributions

Runtime Mechanism: A system coupling projected views with verified JSON Patch writes over shared state, producing structured traces of views, proposals, and verifier decisions.
Footprint Algebra: A formalism for declared read, write, and patch-source regions that supports delegation, composition, and static certificates for reordering independent steps.
PatchBench: A benchmark of 46 hand-authored cases across six domains (finance, marketing, medical, science, software, support). It evaluates the design by separating live actor runs from "no-model" tests using compromised artifacts.

Empirical Results

The evaluation was conducted using a strong actor (GPT-5-mini) and a weaker actor (Mistral 7B) across six settings (Unconstrained, Schema Only, FSM+ACL, View Only, Verify Only, PatchOptic).

Leakage Reduction: Projected reads significantly reduced reported leakage. Under GPT-5-mini, full-state settings had a leak rate of ~31.5%, while PatchOptic reduced this to 0.2% (mean leak runs dropped from ~14.5 to 0.1 per round).
Token Efficiency: Projected-read settings used 11–13% fewer tokens per run compared to full-state settings.
Output Quality: Under the strong actor, projected reads did not degrade accepted-output quality (Content Score remained ~0.927). Consequently, the Semantic Pass rate (quality + no leakage) rose from ~0.61 (Unconstrained) to 0.78–0.80 (PatchOptic).
Verification Efficacy: Runtime verification successfully blocked declared contract violations (phase and scope errors) before commit. In the "no-model" stress test, PatchOptic and Verify Only rejected 100% of compromised artifacts that attempted to cite hidden source paths, whereas settings without patch-source checks (e.g., FSM+ACL) accepted 8/9 such artifacts.
Weak Actor Behavior: For the weaker Mistral actor, PatchOptic achieved the highest Semantic Pass rate (0.690) by combining projection (which prevented leakage) with verification (which blocked invalid patches), compensating for the model's lower intrinsic quality.

Significance and Claims

The paper claims that PatchOptic provides a necessary "contract" between local model actions and global system validity. Its significance lies in:

Decoupling Observation from Commitment: It explicitly separates what the actor may observe (projected view) from what the runtime will commit (verified patch), preventing the model from needing to carry global security obligations.
Composability: The footprint algebra allows for the static verification of delegation, composition, and reordering, enabling safer scaling of multi-agent workflows.
Defense in Depth: By combining projection (preventing the actor from seeing secrets) with patch-source enforcement (preventing the patch from reading secrets even if the actor is compromised or the artifact is injected), the system addresses both prompt-injection risks and compromised artifact risks.

The authors acknowledge limitations, noting that the system trusts the policy author (if the contract is wrong, the system enforces the wrong contract) and does not prevent semantic errors or policy-authorized disclosures. However, they posit that PatchOptic establishes a foundational control layer for safely deploying LLM agents in large shared-state systems.