Skip to content
Riverfront

An honors contract in its research phase · Arizona State University

AI assistants forget the rules you gave them ten minutes ago.

Conversational Riverfront checks every single turn against the constraints you actually set — and catches the drift while the conversation is still open.

Stage
Research
Built so far
Nothing
Interviews
19
Open questions
Five
See it happen How it works Pitch deck ↗
One rule, twenty turns Illustrative
Tone lost by turn 8
Format lost by turn 11
Scope lost by turn 14

Three rules stated at the start of a session. Tone is lost by turn 8, format by turn 11, scope by turn 14.

honored slipping dropped

02 The problem

The rule you set on turn one is gone by turn twenty

Instruction drift is a silent failure. Nothing errors, nothing warns, and the work is usually finished before anyone notices.

A session opens and its terms get set in the first minute. Prose, not bullet lists. Only the file I paste. No recap at the end. Stated once, they are reasonably expected to hold.

Turn 1 — stated once

You: Working through this parser with me. Prose only — no bullet lists. Touch only the file I paste. Skip the recap at the end.

↓  twenty turns later  ↓

Without the layer

You: Why is the tokenizer dropping the last escape?

Assistant: Here's what's happening: • The escape is consumed in `readString()` • The index advances twice I also went ahead and tidied `lexer.ts` and `utils.ts` while I was in there. To summarize, the fix is a one-line change.

✗ Bullet list. Two files that were never pasted. A recap.

With the layer

You: Why is the tokenizer dropping the last escape?

format: prose only · scope: parser.ts · tone: no recap — checked against the response before it was returned

Assistant: The escape is consumed inside `readString()`, which advances the index once on its own account and once again when it returns, so the final character is passed over. The change is confined to that function.

✓ Prose. One file. No recap.

Illustrative. The exchange is reconstructed from the failure pattern described in interviews, not transcribed from one logged session — instrumenting real sessions to measure how often and how early this happens is part of the work ahead, not a result I already have.

They hold for a while. Then tone goes, then scope, and by the twentieth turn you are reading answers against rules you already gave. Nineteen people described the same decay in different words, and they were not all engineers.

He already solves most of it himself — rules files, plus hooks that re-inject the rules on every single prompt.

Interview 04 · Informatics honors student, daily LLM user

People are already building that scaffolding by hand, at their own cost. A rules file makes the constraint present in the context. It does nothing to check whether the constraint was honored on the turn it was given.

03 Why current fixes fall short

Everything that exists solves the problem next door

Three categories of tool sit near instruction drift. Each is genuinely good at something adjacent to it.

Instruction files

CLAUDE.md · system prompts · custom instructions

States the constraints once, at the start of the session.

Where it stops

Nothing ever asks whether the response that just arrived complied.

Memory tools

Supermemory · Mem0

Carries facts and history across sessions so they can be recalled.

Where it stops

Retrieval asks what did we establish? Fidelity asks did you just do what I asked?

Offline auditors

Offscript (CHIIR 2026)

Reviews the conversation after the fact and scores it.

Where it stops

The review arrives at the moment you already notice the problem unaided — once the work is done.

Guardrails are the fourth neighbor, pointed differently again: they enforce a policy the operator set in advance. These constraints belong to the user, arrive in ordinary language mid-conversation, and change as the conversation does.

What is missing in every case is a check that runs on the turn, while the conversation is still open.

04 How it works

A bank, not a reservoir

A structured packet after each prompt-and-response pair, checking the response against the constraints in force at that moment.

After each prompt-and-response pair, a structured packet holding the session’s constraints is fed alongside the exchange, and the response that was just produced is evaluated against the constraints in force at that moment. A violation is caught on the turn rather than discovered later.

The distinction the design turns on is between storage and flow control. A reservoir holds water; a bank decides where it goes. Memory systems are reservoirs — they keep the constraint available. This is a bank.

Per-turn instruction-fidelity loop

A prompt and the model’s response both feed a constraint packet, assembled from the constraints in force at that point in the session. The packet feeds a per-turn check with two outcomes: a response that complies is returned as-is, and one that violates a constraint is flagged and corrected. The violation updates an ordered constraint set, in which a newer constraint supersedes an older one without overwriting it, and that set is what the next turn’s packet is built from.

promptresponseconstraint packetper-turn checkcompliesviolatesreturned as-isflagged, correctedordered constraint set — newer supersedes older, nothing overwrittenformat · scope · tone · whatever the user actually saidin forceupdates

Scroll the diagram sideways

Fig. 1 One turn. The packet is assembled from the constraints in force at that point in the session, the check runs against the response that was just produced, and the outcome updates the constraint set before the next turn.

01

Synchronous with the turn

A violation is caught at the only moment it is still cheap to fix.

Cost — An extra inference per turn.

02

Derived, not authored

Assembled from constraints you already stated, so there is no second document to keep in sync.

Cost — Ordinary language has to become checkable.

03

Ordered and reversible

A newer constraint supersedes an older one without erasing it.

Cost — This is where the layer comes closest to being a memory system.

04

Legible

The packet is a structured object a person can read, so when the layer is wrong you can see why.

Cost — Judgments that cannot be inspected replace one trust problem with another.

Flow control, not memory is the claim. Keeping it true under a layer that persists across breaks in a conversation is the first of the open questions below.

05 Research status

What is settled, and what is not

Nothing is built yet. What follows is what has been settled, what is being tested, and what is genuinely unresolved.

Settled

A competitive landscape audit is complete: the concept is distinct from memory tools, guardrail systems and after-the-fact auditors. That establishes the idea is not already built, not that it will work.

Being tested

Nineteen interviews, every participant describing instruction drift without being led to it. Two refinements came out of the wider set: drift is not always gradual, and forgetting is not the only failure — more than one person described an assistant that still held the rule and implemented it badly.

That supports a real, self-reported pain across a wide range of work. It does not yet establish how often drift occurs, how early, or on which kinds of constraint.

Open — not yet answered

Open · unanswered

How does the layer persist constraints across breaks without becoming the memory layer it is defined against?

Persistence and an ordered, reversible constraint set are both carried state. The distinction is conceptually clear; the implementation is not.

Open · unanswered

How does a constraint stated in ordinary language become something a check can evaluate?

"No bullet lists" is nearly mechanical. "Match the tone of the last thing I wrote" may not be checkable at all.

Open · unanswered

What performs the check, and can it be cheaper than the model being checked?

If judging compliance needs a model as capable as the one under review, the loop is circular and the economics are poor.

Open · unanswered

What does a check on every turn cost, and is that tolerable?

A second inference per turn, in latency and spend. Measurable early, with no users, so it should be measured early.

Open · unanswered

When a newer constraint contradicts an older one, what should happen?

Tracking the change does not say which constraint governs the current turn, or how the user is told a supersession was inferred.

Where the evidence is thin

Eight of the nineteen already pay for an assistant, which is not the same as willingness to pay for this. The conversation that has not happened is with an organizational buyer who treats unreliable output as a cost with a number attached.

The second gap is a finding against this site: several participants outside computer science said the rules-files framing did not apply to them. The problem generalizes past engineers. The way this page explains it does not, yet.

Marketplace conversation log

19 interviewed · 8 payers · 11 non-payers

    • Drift shows up as tone rather than format — answers slip back into sounding generic.
    • Spends roughly twenty minutes a session cross-checking answers across three different models.
    • Pays for a subscription only to remove prompt limits, not for quality.
    • Would use the product, and offered introductions to peers doing heavy agentic coding.
    • Drift appears during long, rapid-fire question-and-answer sessions.
    • Resolves it with a one-line reminder or by starting a new chat, so the pain stays minor.
    • Would adopt only if it added no delay and raised no false flags.
    • Would not pay, and suggested asking which task types drift the most.
    • Drift shows up across chats rather than within one — an instruction held in a session was gone in the next.
    • Solved it with account-level global instructions.
    • Wants the assistant to discuss an approach before it starts building.
    • Would trial before adopting, and pays only for higher usage limits.
    • The worst drift was action, not style — a public post when a draft was wanted, and a deployment that had been reserved.
    • Already mitigates most drift with rules files and hooks that re-inject the rules on every prompt.
    • Would not adopt unless it reliably catches fuzzy issues such as tone.
    • Verifying a large change takes far longer than verifying a small one.
    • Drift broke a hard constraint — a one-page resume grew past one page as the bullets were improved.
    • Takes no preventive steps and simply re-asks.
    • What resonated most was the assistant doing tasks it had been told not to do.
    • Would use it to save time, but would not pay for it.
    • The conciseness rule fades as a chat grows longer, and it is the only rule repeated.
    • Sets ground rules at the start of every chat, then fact-checks once and trusts the rest.
    • Encounters lost constraints daily and would use the product.
    • Pays for reasoning quality rather than for higher limits.
    • Format and conciseness rules were ignored even on a simple paraphrase.
    • Has no workaround and simply keeps repeating the instruction.
    • Spends at least fifteen minutes verifying output.
    • Related to everything on this site and would use it; pays for a subscription only for more responses.
    • An instruction failed on a file-export request and was forgotten on the very next ask.
    • Links the drift to running out of context window.
    • Fixes it with a new chat, or by paying for a higher tier; about two minutes to verify.
    • Rarely hits the problem because the tasks are simple, so would adopt only if the inconvenience grew.
    • The main rule was to stay within uploaded materials, and the assistant still added outside information.
    • Has to re-upload sources when it strays.
    • Said rules files and hooks felt irrelevant to a non-CS user.
    • Would use it to stop repeating instructions, but not if it slows the assistant, flags correct answers, or needs setup.
    • The assistant looped the same wrong answer in new packaging despite repeated clarification.
    • It ignored her first instruction about ten turns later, and starting a new chat did not help.
    • Had no way to verify the output at all.
    • Instruction drift matched her experience exactly; would use it for tedious problems but will not pay.
    • Asked for multiple-choice questions only, and the assistant drifted into matching, fill-in-the-blank and short answer.
    • Format rules are ignored on summary pages too; re-asks, with no workaround.
    • The coding and rules-file material on this site did not apply to her, and the writing was hard to follow.
    • Would adopt only if it were extremely easy to use; suggested asking how much people actually understand about AI.
    • The assistant kept 'correcting' code that was intentionally reversed for the hardware, and had to be reminded repeatedly.
    • Dropped some instructions in order to accommodate others.
    • No workaround beyond repeating herself; spots errors quickly and fixes them by hand.
    • Would not use it if it added latency, and knows nobody who pays for AI tools.
    • The main pain is accuracy rather than drift — differential equation answers are often simply wrong.
    • The only fix was forcing the assistant to work step by step, very slowly.
    • Verifies by re-solving the problem and checking the textbook.
    • Prefers self-teaching for retention; would use a 'perfected' assistant only as a last resort.
    • A short-summary rule mostly held, but in question-and-answer the assistant lost track of the question and went in circles.
    • No workaround beyond re-telling it.
    • Spends about ten minutes verifying against notes and search.
    • 'When it forgot my rules' felt closely accurate; unsure about adopting the product.
    • A filtering standard set early in a pipeline was silently dropped after several iterations, and only caught during verification.
    • Now pins rules explicitly — keep this original file, change only this one thing.
    • Builds separate test programs to check results.
    • Drift matched his experience, but he corrects errors live and is unsure he needs the product.
    • Asked for written answers rather than pasted links, and had to repeat the request several times.
    • No workaround beyond re-asking.
    • Verifies by checking cited links and asking for more citations.
    • Would consider a tool that makes assistants more consistent, but will not pay while the free tier is good enough.
    • Told the assistant to paste exact points onto slides; it rewrote them when later asked to add an image.
    • It kept flip-flopping answers even when told to give only correct ones.
    • Prevents drift with very detailed prompts, and restarts in a new tab when output goes bad — which costs a lot of time.
    • The rules-files-and-hooks framing felt very accurate, and she would definitely use the product.
    • Asked for natural, concise output and the assistant could not hold it.
    • Drift is worst in image generation and editing, where it repeats the same mistake over and over.
    • Fixes it by starting a new chat with a clearer prompt; verifies by making the assistant justify its answer.
    • Would choose between tools on pricing, accuracy and availability.
    • The assistant reintroduces things that were explicitly removed, and fixing one issue brings back an old one.
    • Drift is not always gradual — it can break a rule immediately, or after dozens of correct turns.
    • Sometimes it remembers the rule and implements it badly, which is a different failure from forgetting.
    • Already pays for a subscription and already uses custom instructions, rules files and progress notes; would try this only if it did not interrupt the workflow and was not a second subscription.
    • Asked how the layer separates persistent rules from one-off ones, and how a user views, edits or removes a tracked constraint.

Scroll the list, then hover a row to read what that conversation established — or tap it, or tab to it. Participants are listed by field of study rather than by name: agreeing to speak with a classmate for a course assignment is not the same as agreeing to be named on a page that stays online indefinitely and is indexed by search engines.

06 What gets built, and when

Roadmap

Phases, not dates, past the point where dates would be invention. Each phase answers something the one before it raised — and a phase that returns the wrong answer should stop the ones after it.

  1. Fall 2026

    complete

    Problem and landscape

    Competitive landscape audit complete. Nineteen interviews establishing that instruction drift is real and self-reported.

  2. Fall 2026

    under way

    Marketplace conversations

    Find the organizational buyer the argument assumes and has not met, and a way of explaining the work that lands outside computer science.

  3. Next

    planned

    Measure the drift

    Instrument real long sessions and establish a baseline: how often constraints are violated, how early, and on which classes. No interface, no product.

  4. Next

    planned

    Formalize the constraint packet

    Decide what a constraint is in this system, and which classes are tractable enough to check. Where the open questions resolve or force a redesign.

  5. After the above

    contingent

    Prototype the per-turn check

    A narrow loop over format and scope against a cheap checker. The point is a cost figure and a fidelity figure, not a usable tool.

  6. After the above

    contingent

    Evaluate honestly

    Does per-turn checking reduce drift against the baseline, and at what cost? A negative result is a finding and a reason to stop.

  7. Beyond the research

    contingent

    Make it usable by someone else

    Only if the evaluation holds. Listed last because it is the part most likely to change shape entirely.

07 Honors contract

Why this site exists

This site is the public deliverable of a Barrett Honors Contract in FSE 301.

An honors contract lets a Barrett student take a regular course further than its requirements. In FSE 301, Entrepreneurship and Value Creation, that means taking a venture past the classroom and putting it somewhere the public can see it.

Course
FSE 301 — Entrepreneurship and Value Creation
Institution
Barrett, The Honors College · Arizona State University
Approved by
Professors Joy Griffin and Brent Sebold
Deliverables
This site, the pitch deck and the video pitch — public indefinitely

Most honors contracts end with something you can use. This one does not, and saying otherwise would be the wrong kind of ambition. Conversational Riverfront is early-stage research: the problem is evidenced, the architecture is a proposal, and the questions that matter most are still open. The site sets out each of those in turn.

08 Pitch materials

Deck and video pitch

The evidence-based pitch deck and the video pitch.

The deck is embedded from Google Slides, shared view-only. The video sits at a fixed path on a domain I own — /pitch.mp4 — with no version number and no hash, so a link handed out today keeps resolving.

V3 pitch deck
Open the deck ↗
Video pitch /pitch.mp4

Not yet published. Self-hosted, so the link depends on no other account.

09 Who is doing this

About

Vishesh Singh Rajput

Vishesh Singh Rajput

Computer Science (Artificial Intelligence) · Barrett, The Honors College · Arizona State University

The idea came from using these systems for hours at a stretch and noticing that the constraints I set at the start were the first thing to go. Customer research turned a private annoyance into something with a competitive landscape and a set of questions I cannot yet answer.

Contact

Disagreements especially welcome — five of the questions on this page are still open. If you run a team where drifting output costs real review time, that is the conversation this project is most missing.

vrajput5@asu.edu