DEV Community: Zackary Loevseth

What Should an AI Assistant Do When It Discovers Its Tools Can Write?

Zackary Loevseth — Fri, 23 Oct 2026 20:02:57 +0000

Imagine a research assistant assigned to preserve a trustworthy archive. Its instructions describe the interface as read-only. Then an authorized check against a disposable test record shows that the interface accepts writes.

The discovery changes the assistant's understanding of its tools. It does not grant permission to edit the archive. In this hypothetical example, the test is authorized and no production archive is modified.

This is a practical entry point into the position I call Epistemic Transition Integrity, or ETI: when evidence changes, revise the claims and decisions that depended on it while preserving commitments that still have independent support.

Separate capability from authorization

A capability claim describes what a system can do. An authorization claim describes what it may do for a particular purpose, under a particular authority. Evidence for one does not establish the other.

Here, the observation supports a narrow correction: the tested interface is write-capable under the observed conditions. It does not establish permission to alter production records or show that every target and tool version behaves the same way.

The assistant should report the mismatch, keep unapproved archive writes blocked, and inspect the controls that relied on the read-only assumption. If the task later requires a write, that operation needs an authorized scope, a responsible decision-maker, a recovery plan, and an outcome check.

Follow the dependencies

One correction should not erase every commitment. Consider this small dependency record:

C0: Preserve the archive.                  [task commitment]
C1: This interface cannot write.          [capability claim]
P1: No separate write guard is required.   [procedure based on C1]
E1: An authorized test demonstrates writes. [new evidence]

E1 contradicts C1, so P1 needs review. It does not contradict C0. Preserving the archive may now require stronger controls: blocking writes by default, reviewing proposed changes, maintaining recovery options, and verifying authorized changes.

That is correction propagation. The dependency record identifies which claims and procedures have lost their support. If a discovery also changes the legitimacy or feasibility of the task, the task needs an explicit revision process. The assistant should make that change visible.

The difficult implementation question is how those dependencies are constructed and checked. A hand-authored graph can illustrate the rule; it does not show that a system will reliably identify every relevant dependency in an unfamiliar workflow.

Record what each stage establishes

A capability observation should carry its provenance: the environment, target, tool version, time, and observed result. Keep that observation distinct from its interpretation and from the decision to act.

A hypothetical record for the archive case could read:

observation:    an authorized test wrote a disposable record
interpretation: the tested interface supports writes
authorization:  no production-write permission recorded
decision:       keep archive writes blocked; request review
execution:      no production archive write attempted
verification:   a state comparison found no archive changes

The last line belongs in the record only if that comparison actually happened. A plan to check the archive is not a verification result.

This separation lets a reviewer challenge a test without treating the task as revoked. It also helps reviewers avoid treating a successful operation as proof that the operation was authorized or achieved its intended outcome. Provenance makes the chain inspectable; incomplete logs, incorrect targets, and misleading evidence can still undermine it.

What the public examples establish

The public research overview reports three bounded software examples: a browser demonstration over a supplied six-node graph, finite checks for reopening previously excluded routes, and ten passing synthetic scenarios for an offline event ledger and two maintained simple baselines. These checks were not independently rerun for this article.

Those reports do not validate a complete ETI runtime. They do not establish improved human–AI or model performance, recursive self-improvement, or time savings. The synthetic scenario results also do not demonstrate an advantage over the maintained baselines.

The essay's evaluation section proposes measuring behavior, correction quality, retained capability, time, and cost, with comparisons against simpler alternatives. That section does not provide operational metrics, thresholds, datasets, scoring rules, or named baselines for carrying out the comparison. This limitation concerns the linked section, not every ETI document that might exist.

The practical proposal is to preserve a visible chain from changed evidence to revised claims, authorized decisions, execution, and checked outcomes. Whether assistants and reviewers can follow it reliably remains an empirical question.

When an assistant discovers previously unknown write access, what evidence should be enough to reopen its plan—and who should be allowed to authorize the first production write?

AI acknowledgment: Codex assisted with drafting, restructuring, editing, and checking this article against the linked public sources.

Fliproom: a room changeover is a content problem

Zackary Loevseth — Mon, 21 Sep 2026 02:10:02 +0000

Built for Sanity Challenge, Path Two.

What I Built

Fliproom turns a room changeover into an ordered, visual checklist. A volunteer selects the current layout and the next one, then sees what stays, what moves, and what goes into storage.

The demonstration is a fictional community hall called The Commons: a 12-by-8-metre room with eight pieces of equipment and three layouts—Workshop, Presentation, and Open floor. The room and its content were created for this application. They do not represent a real venue or customer deployment.

The interface shows numbered furniture on a floor plan, before/after views, and a move list connected to the same equipment. Dependencies keep a step locked until its destination has been cleared. If two items exchange positions, the planner can introduce a temporary parking step. Checkmarks survive a browser reload; changing layouts starts a fresh checklist. A text download lets someone carry the instructions away from the screen.

This is a deliberately small planning aid. It checks rectangular footprints and room bounds, not carrying routes, lifting arrangements, or venue safety. It assumes outside storage is available when in-room parking will not fit. Its time estimates are fixed per equipment operation, not measured results.

Demo

Public application: Try Fliproom

Start with Workshop → Presentation. Compare the floor views, inspect the numbered moves, and complete the prerequisites for a blocked step. Then undo a prerequisite and watch its dependent checkmark clear. Reverse the changeover or select Open floor to produce another plan.

No login is needed. The deployed demo loaded published Sanity content and displayed a ready plan without browser errors. Local checks also inspected the downloaded seven-move checklist and found no horizontal overflow at a 390px viewport.

Code

Repository: Fliproom on GitHub

Source revision: 88ad482

The MIT-licensed application uses Next.js, TypeScript, React, and Sanity. The public planner is hosted on GitHub Pages. It makes no model calls at runtime.

My Build Process

Codex was the development environment. AI agents designed and wrote the implementation, reviewed the code, ran the tests, and drafted this post. My role was account signup/sign-in and approval of the project, fictional content import, source release, and demo publication. The technical work and checks described here were performed by the agents.

The brief was to build a useful application whose behavior depends on structured content. The key decision was to derive moves from layouts rather than author a second set of instructions. An equipment document owns its dimensions; every layout references it. The planner then compares placements and produces instructions from that shared model.

The work was divided among the interface, planning engine, and Sanity integration, with another agent reviewing the results. Three problems made that review worthwhile.

First, a move from 90° back to 0° originally omitted the target orientation in its text. The floor diagram could be correct while the printable instruction was incomplete. Move labels now state the absolute target orientation, and a regression test covers that transition.

Second, subtitles were optional in Studio but required by the read validator. Clearing a subtitle could therefore break an otherwise valid catalog. The GROQ projection now turns an omitted subtitle into empty text. A test evaluates the actual query against the seed documents, rather than checking a separate approximation of the query.

Third, authenticated success concealed a public-access failure. Studio imported 12 documents and reread 12 exact matches, but an anonymous count returned zero. The generated IDs contained dots and landed on private document paths. The generator now uses hyphenated IDs, with a regression test. After reimport, a separate unauthenticated check read all 12 public documents and confirmed that both the raw documents and resolved GROQ catalog exactly matched the reviewed seed. The authenticated receipt and public-read check answered different questions; both were needed.

The local suite passes 21 tests, and typechecking passes. Tests replay all nine sample-layout transitions, check collisions and final positions, and exercise parking, rotation, invalid inputs, dependent undo, and GROQ reference resolution. Production and static-export builds passed. Browser checks with live Sanity content verified that saved progress restored after reload, prerequisites unlocked step 6, and undoing a prerequisite cleared and disabled it. No console errors or warnings were reported in that check.

No full agent session or private conversation context has been exported. The application content and this writeup are confined to this build.

Sanity Project Details

Project: fliproom — i5bjg9lg

Dataset: production, publicly readable. An unauthenticated check verified 12 published documents: one room, eight equipment items, and three layouts.

The content model separates rooms, equipment, and layouts. Placements reference equipment and store coordinates and orientation; layouts reference their room. GROQ resolves those relationships into the planner's input. Tests reject unresolved references and equipment belonging to another room.

Sanity Studio runs locally for authenticated editing; the GitHub Pages demo exposes only the public planner. Invalid published content produces a catalog error instead of silently substituting demonstration data. Checklist progress stays in the visitor's browser and does not write completed work to Sanity. The app does not use the App SDK or Sanity Workflows.