AEL Runtime Accountability — V1

(Required read: AEL)

Why and how

This is a V1 design for making AI-assisted work more accountable without pretending that AI can be made perfectly reliable.

The starting problem is not simply that AI makes mistakes. AI will make mistakes. The more interesting problem is what happens when the AI silently chooses a path, generates a large amount of material down that path, and leaves the human to discover the mistake after the cost has already accumulated.

The design goal is therefore:

Don't try to make the AI more trustworthy. Make its behavior legible enough that a human can catch, locate, and correct the error cheaply — before sunk cost accumulates.

The architecture came from practical AI use and from mapping an earlier self-driving-car discussion about memory layers onto the user's own AI pain points. Other AI systems were used to elaborate and pressure-test the architecture; they are not the source of it.

The central question is accountability:

 If AI cannot take responsibility, and the companies building or deploying it may not always be the party standing at the immediate decision point, whose decision is it when something goes wrong?

The answer here is not to dump responsibility on the user. It is to make the user's actual decision point visible and meaningful.

A human can be wrong. A human can choose a bad strategy. A human can believe something the AI thinks is wrong. A human can change their mind when facts change. The architecture is not a truth-enforcement system. It is an accountability system.

1. Accountability starts before execution

A common model of human oversight looks like this:

AI interprets request

        ↓

AI chooses strategy

        ↓

AI develops strategy

        ↓

AI generates large output

        ↓

HUMAN REVIEWS

There is technically a human in the loop. But the human may not have chosen the consequential path. They are being asked to audit a decision after the AI has already made it. That is not the same as meaningful delegation.

The architecture instead moves the human decision point forward:

AI identifies materially different paths

        ↓

cheap branch representation

        ↓

HUMAN CHOOSES

        ↓

AI develops selected path

The purpose is not to make the human inspect everything. It is to make the human inspect the small number of decisions that determine what everything else will become. This connects to existing human-oversight work. NIST's AI Risk Management Framework discusses defining human roles and responsibilities in human-AI interaction, including cases where AI recommends and a human decides.

[NIST — AI Risk Management Framework, Human-AI Interaction](https://airc.nist.gov/airmf-resources/airmf/appendices/app-c-ai-risk-management-and-human-ai-interaction/)

[NIST — AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework)

The EU AI Act similarly treats human oversight as something that must allow people to understand, interpret, override and intervene, rather than merely having a human somewhere in the system.

[EU AI Act — Article 14: Human Oversight](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-14)

2. Mechanism 0 — Materiality Gate

Not every request contains a decision worth exposing. Branching itself costs attention and time. If the system branches on everything, accountability machinery becomes bureaucracy.

The test is therefore not:

Is this request difficult?

It is:

Am I about to make a choice on the user's behalf that materially determines what happens next?

For example:

- “Summarize this document” can be difficult but usually has no consequential decision boundary → execute directly.

- “Make an image for this essay” can look trivial but contain several materially different interpretations → expose the branches.

The materiality decision must itself remain visible and overridable. 

If the AI decides no branching is needed:

“Treating as single-path. Say ‘branch it’ if you want options.”

If the AI decides branching is needed:

“Branching because this has material choices. Say ‘just do it’ to skip.”

The user can also ask for a recommendation:

“I don't know — recommend.”

That creates a different accountability shape: AI recommends, human accepts or rejects, AI executes.

The important point is that the user can redo the original query with branching if the AI got the materiality decision wrong. The system should not try to reverse-engineer branches from an already-generated answer.

3. Mechanism 1 — Branch Exposure

For a materially ambiguous request, the AI should surface the real decision points before building any of them out:

A: literal representation — clearest, least interpretive.

B: structural metaphor — more abstract, but preserves the underlying relationship.

C: process/sequence — emphasizes change over time.

The user chooses. The branch description must include the material trade-off. Merely saying “Option B” is not meaningful choice. The AI does not need to expose private chain-of-thought. It needs to expose the consequences of the choice.

This is what turns accountability from:

“You asked me to do it.”

into:

“You saw the materially different paths, understood the relevant trade-off, and chose this one.”

That distinction matters because automation bias is a real phenomenon: humans can accept incorrect AI recommendations, particularly when the AI is perceived as useful or authoritative.

[Kücking et al. — Automation Bias in AI Decision Support, PubMed](https://pubmed.ncbi.nlm.nih.gov/39234734/)

[Goddard, Roudsari & Wyatt — Automation Bias: Empirical Results](https://www.sciencedirect.com/science/article/pii/S1386505614000148)

Branch exposure does not attempt to eliminate automation bias by making the AI more persuasive. It gives the human a more legible decision boundary.

4. The ten-paragraph problem: AI can hijack the context simply by talking

This is one of the original practical complaints behind the architecture. The problem is not just:

“AI gave me a wrong answer.”

It is:

AI gave me ten wrong paragraphs that I had to read before discovering that it had chosen the wrong direction.

There are two costs.

Verification cost

The human has to consume the generated material to discover that the branch itself was wrong.

Context cost

Those ten paragraphs are now sitting inside the active conversation. They can influence what the AI does next, even after the human rejects the direction.

So the failure becomes:

AI silently chooses branch

        ↓

AI generates ten paragraphs

        ↓

HUMAN discovers branch is wrong

        ↓

verification time already spent

        ↓

wrong material remains in context

        ↓

next attempt is influenced by rejected material

This is context-window hijacking by verbosity.

A context window is a shared, bounded workspace. Imagine a couple gets married and discovers they have one small wardrobe. One person fills 95% of it. The other person technically still has access to the wardrobe, but it is no longer functioning as a shared space.

AI must not be allowed to do the same thing to a shared context simply by generating more tokens.

AI verbosity must not equal contextual authority.

Long-context research gives external support for the narrower technical point that more context does not necessarily mean equally usable context. Liu et al.'s Lost in the Middle found that retrieval performance can degrade depending on where relevant information sits within a long context.

[Liu et al. — Lost in the Middle: How Language Models Use Long Contexts](https://arxiv.org/abs/2307.03172)

More recent work has continued examining the relationship between information retrieval demands and long-context behaviour.

[Lost in the Middle: An Emergent Property from Information Retrieval Demands in LLMs](https://arxiv.org/abs/2510.10276)

These papers do not establish the exact “ten AI paragraphs hijack the user's context” mechanism. That is an architectural inference from the observed failure mode.

5. AI output must be distilled before acquiring persistent working-context weight

The complete AI response belongs in the chat history. It does not follow that the complete response deserves to remain in active context at full weight.

Instead:

AI generates large response

        ↓

response remains in CHAT HISTORY

        ↓

context distillation

        ↓

only relevant information enters ACTIVE CONTEXT

Ten paragraphs might become:

Active branch:

AI interpreted request as X.

Status:

Not accepted by user.

Relevant constraint: Y.

Evidence: Z.

User decision: Pending.

The original ten paragraphs still exist in history. Nothing has to be erased merely because it is no longer active. But they do not get to occupy the working context simply because the AI generated them.

This creates an important asymmetry:

User-generated constraints are evidence. AI-generated interpretation is the model's own prior output.

The runtime design therefore treats AI-generated material as increasingly compressible as it ages, while user constraints and decisions retain higher contextual weight.

The purpose is not to erase AI output. It is to stop verbosity from becoming authority.

6. Mechanism 2 — Pivot-with-Reset

I pivot when I see a rabbit hole. I also change my mind when the facts change. An initial idea is not a commitment merely because I was the person who proposed it.

That means the system must make pivoting cheap.

If a branch is rejected, the system should not simply tell the model:

“Ignore the previous branch.”

That leaves the branch in the context.

A real reset is a context operation:

stable state

    ↓

branch

    ↓

development

    ↓

USER: reject

    ↓

discard polluted local runtime

    ↓

rehydrate stable state

    ↓

new branch

The failed branch becomes zero-weight in the active runtime. Its detailed output remains historical, but it stops steering the next attempt. This is the practical meaning of pivot-with-reset:

Discard the polluted runtime and rebuild it. Do not ask the model to forget something it can still see.

The AEL runtime design makes this explicit: reset is the destruction and rehydration of the local context object, not a semantic instruction to the model.

7. Local context has a real lifecycle

The chat is a persistent object.

Conceptually:

CHAT

├── history

└── summary / chat context

The summary exists for cheap loading and token budgeting. It does not replace the history.

When a chat becomes active, a runtime context object is assembled from:

• account context

• project context

• chat history/summary

• active frame

• relevant tags

• current branch/state

That produces:

LOCAL CONTEXT

Local context is temporary and mutable. It is what the model actually works against. The local context carries the current `chat_id`.

A new query inside the same chat does not destroy the local context. A query belonging to a different chat does.

query.chat_id == local_context.chat_id

        → same runtime; update in place

query.chat_id != local_context.chat_id

        → destroy local context

        → load new chat

        → hydrate new runtime

This boundary is based on chat identity, not message/query identity.

That gives two different reset triggers:

1. Explicit pivot: same chat, but the user rejects the current branch; rebuild the local runtime from the appropriate stable point.

2. Chat transition: different chat ID; destroy the old runtime and hydrate the new chat automatically.

Pollution from one chat therefore has no path into another through the shared runtime object.

8. Chat history and active context are deliberately different

The distinction is simple:

Chat history:

What happened.

Chat summary/context:

What is useful to carry when the chat is not active.

Local context:

What the currently active chat has loaded for the model to work against.

They have different lifecycles.

HISTORY

  ↓

CHAT SUMMARY / CONTEXT

  ↓

hydration

  ↓

LOCAL CONTEXT

  ↓

mutable runtime

  ↓

discard / rebuild

This is what makes walk-back possible without pretending the past never happened.

9. Persistent memory needs a walk-back too

The same problem can occur one level higher. A messy chat can be summarized into account memory:

messy conversation

       ↓

distillation

       ↓

account memory

       ↓

future chats

Now the old interpretation can influence future work.

The answer does not have to be deletion.

A memory can lose authority before it loses historical existence.

ACTIVE

   ↓

no confirming use for N days

   ↓

DORMANT / READ-ONLY

   ↓

new confirming evidence

   ↓

ACTIVE

An explicit reversal can act immediately rather than waiting for decay. This is intentionally a simple batch-processing problem in V1. It does not require a complicated live reasoning system.

The key distinction is:

Memory can persist longer than authority.

10. Projects remain inside the account

V1 does not need a separate universe for projects and collaboration because the actual use case does not require one yet.

A project is an account-owned wrapper with its own context:

ACCOUNT

├── account context

└── PROJECTS

    ├── Project A

    │   └── chats/context

    ├── Project B

    │   └── chats/context

    └── Project C

        └── chats/context

Project-specific material remains project-specific unless deliberately promoted. There is no need to invent multi-user collaboration infrastructure until the problem is actually encountered.

11. Mechanism 3 — Failed-Pattern Circuit Breaker

AI can also get trapped in a patching loop:

AI attempt

 ↓

user: no

 ↓

AI patch

 ↓

user: still no

 ↓

AI patch

 ↓

user: still wrong

 ↓

...

Normal iteration should not trigger a reset. The circuit breaker is specifically for repeated rejection of the same underlying strategy. After N such failures, the system stops patching and proposes a clean strategic alternative.

The counter should be visible:

“2 of N. Next rejection triggers a clean-slate proposal.”

The system counts rejected approaches, not ordinary tuning messages.

12. Mechanism 4 — Account Context

Persistent per-user context already exists as a product concept. The relevant V1 question is not whether memory exists, but how much authority old material should retain. Account context can hold personal takeaways, conventions and other durable information. Project context remains scoped to projects.

But local-to-account promotion should not mean that every messy conversational artifact becomes a permanent rule. Distillation, weighting and eventual dormancy provide the containment boundary.

13. Locale-specific knowledge must remain conditional

A separate problem appears when the system learns rules that are not universal.

Examples include:

- ecosystem conventions;

- field-specific standards;

- regulatory jurisdictions;

- organization-specific house style.

These should not be flattened into one global rule. The architecture therefore treats locale-like information as tagged and conditional:

• locale-type

• locale-identifier

• rule

• confidence

• source

The important distinction is between an externally checkable ecosystem/field rule and a private organization preference.

V1 does not need to solve every possible locale-discovery problem. It only needs to preserve the boundary rather than averaging conditional rules into a fake universal default.

14. Delta-first delivery

The same accountability principle applies after a branch has been selected. If I ask for a substantial modification to an existing artifact, the AI should not make me inspect the entire rewritten artifact merely to discover what changed.

Instead:

USER REVISION REQUEST

        ↓

DELTA / IMPACT SUMMARY

        ↓

HUMAN CHECK

        ↓

FULL ARTIFACT

For example:

Changed hint acquisition from +1 to +2 for premium users. Existing storage unchanged. UI unchanged. No change to completion logic.

If that is wrong, I can reject it immediately.

If it is right, the expensive artifact can be generated.

This is the same design principle as branch exposure, applied one level later:

Verify the cheap representation of the consequential change before consuming the expensive representation.

15. Why the architecture is not trying to make AI trustworthy

The central assumption is deliberately weak:

AI will continue to make mistakes.

The architecture does not need to make AI infallible. It needs to make failures cheap to locate. The design therefore moves accountability toward decision boundaries:

material choice

      ↓

visible branches

      ↓

human choice / acceptance

      ↓

AI execution

      ↓

cheap delta verification

      ↓

result

If the branch is wrong:

reject

 ↓

reset

 ↓

rehydrate

If the memory becomes stale:

weight decays

 ↓

dormant/read-only

If the AI produces too much:

• full output → history

• load-bearing information → active context

The system does not have to claim that the AI is trustworthy. It has to make the AI's participation legible.

16. Why accountability matters legally as well as personally

The legal environment is already forcing questions about where responsibility sits when AI produces consequential output. In 2026, the Munich I Regional Court held Google liable in a case involving false statements generated by its AI Overview feature. The case is subject to appeal and should not be treated as a universal rule, but it is a useful example of a company not being able to make responsibility disappear simply by pointing at automated generation.

[Library of Congress — Germany: Court Holds Google Liable for Incorrect AI Overviews](https://www.loc.gov/item/global-legal-monitor/2026-07-17/germany-court-holds-google-liable-for-incorrect-ai-overviews/)

The Mobley v. Workday litigation similarly illustrates the difficulty of locating responsibility when an AI vendor's system becomes part of another organization's consequential decision process.

[Mobley v. Workday — Court materials](https://law.justia.com/cases/federal/district-courts/california/candce/3%3A2023cv00770/408645/267/)

These cases do not establish a universal rule that “whoever occupied the decision point is liable.” The narrower point is enough:

Responsibility has to be located somewhere in an AI-mediated decision chain.

Decision-point legibility makes that chain easier to understand before a dispute exists.

17. The accountability boundary

The architecture deliberately does not move accountability onto the AI.

The AI can:

- identify options;

- explain trade-offs;

- recommend a path;

- execute a selected path;

- report deltas;

- maintain scoped contextual state.

The human can:

- choose the branch;

- accept or reject a recommendation;

- pivot;

- reset;

- change their mind;

- override the materiality decision;

- reject a generated result.

The system should therefore preserve the difference between:

- User chose X

- AI recommended X and user accepted it

- AI inferred X

- AI generated X

- External evidence supports X

These are different origins and should not silently collapse into one another. The point is not to make the user responsible for everything the AI does. The point is to prevent the system from later pretending that the human made a decision that the human never meaningfully saw.

18. The V1 architecture

ACCOUNT

│

├── account context

│

└── PROJECTS

    │

    └── PROJECT

        │

        └── CHATS

            │

            ├── history

            └── chat context / summary

                     │

                  hydration

                     ↓

              LOCAL CONTEXT

               chat_id = X

                     │

                     ▼

              MATERIALITY GATE

                     │

            ┌────────┴────────┐

            │                                                   │

         trivial          material

            │                 │

         execute           branch

                               │

                       human choice

                              │

                              ▼

                          execution

                              │

   ┌────────┴────────┐

    │                 │

     result           revision

                               │

                        delta first

                               │

                         human check

                                │

     ┌────────┴────────┐

     │                 │

  accept           reject

      │                     │

      │            reset

      │                   │

      └────────┬────────┘

                                 │

                                ▼

                    persistent context

                                 │

                      decay / correction

                                  │

                   active ↔ dormant

The active runtime remains bounded. AI-generated material is compressed rather than allowed to occupy the workspace merely through volume.

Rejected branches are discarded from active runtime. Changing chat IDs destroys and rebuilds the local context. Persistent context can lose authority without being erased.

Projects remain scoped within the account. Branching appears when a consequential choice exists, not merely because a request is difficult.

19. What V1 is deliberately not

V1 is not:

- a universal AI-safety framework;

- a claim that AI can be made reliable enough to eliminate human judgment;

- a requirement that humans verify every AI output;

- a truth-enforcement system;

- a multi-user collaboration architecture;

- a giant provenance graph;

- a requirement for AI to explain its private reasoning;

- a demand that every request become a multi-step approval process.

Later versions may test additional mechanisms such as richer provenance/origin tagging, extract-and-reset workflows, more differentiated decay rules, or faster materiality heuristics. Those are not required to make V1 work.

V1 is intentionally frozen around the problems that produced it.

20. The actual thesis

The problem with AI accountability is not simply that AI can be wrong. Humans can be wrong too.

The problem is that AI can choose a direction, generate enormous amounts of material, and leave the human holding the consequences without having had a meaningful decision point along the way.

That produces the particularly nasty feeling of:

“I don't know what it was doing, and now I have wasted hours.”

Branch exposure fixes the first part.

Pivot-with-reset fixes the second.

Context distillation prevents AI verbosity from taking over the shared workspace.

Chat/runtime separation gives the reset an actual object boundary.

Memory decay gives persistent context a walk-back.

Delta-first delivery makes verification cheap after the strategy has been chosen.

Materiality prevents the accountability machinery from becoming its own burden.

And underneath all of it is one rule:

 AI should carry the expensive generation; humans should retain control of the consequential decisions that determine what gets generated.

The objective is not to eliminate mistakes. It is to make mistakes locatable, reversible and attributable to a meaningful decision point before the cost of discovering them becomes enormous.

That is the V1.

Supporting documentation

Human oversight and accountability

- [NIST — AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework)

- [NIST — Human-AI Interaction](https://airc.nist.gov/airmf-resources/airmf/appendices/app-c-ai-risk-management-and-human-ai-interaction/)

- [EU AI Act — Article 14, Human Oversight](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-14)

Automation bias / human over-reliance

- [Kücking et al. — Automation Bias in AI Decision Support](https://pubmed.ncbi.nlm.nih.gov/39234734/)

- [Goddard, Roudsari & Wyatt — Automation Bias: Empirical Results](https://www.sciencedirect.com/science/article/pii/S1386505614000148)

Long-context behaviour

- [Liu et al. — Lost in the Middle: How Language Models Use Long Contexts](https://arxiv.org/abs/2307.03172)

- [Lost in the Middle: An Emergent Property from Information Retrieval Demands in LLMs](https://arxiv.org/abs/2510.10276)

AI liability / responsibility

- [Library of Congress — Germany: Court Holds Google Liable for Incorrect AI Overviews](https://www.loc.gov/item/global-legal-monitor/2026-07-17/germany-court-holds-google-liable-for-incorrect-ai-overviews/)

- [Mobley v. Workday — Court materials](https://law.justia.com/cases/federal/district-courts/california/candce/3%3A2023cv00770/408645/267/)

Internal design material

- AEL Runtime Accountability — Design Notes — the technical companion containing the object model, hydration lifecycle, materiality gate, branch exposure, pivot-with-reset, local/account boundaries and AI-output weighting.

- Memory Prism / AEL essay corpus — the underlying AEL material, including Vive et Vivere Sinas and AEL and the Machine.

The external material supports specific pieces of the architecture. It is not the origin story. The architecture originated in the user's actual interaction failures with AI and was subsequently elaborated and pressure-tested across multiple AI systems.