DEV Community: davidvk89

The Backwards-Verse Early Access v0.8b is public.

davidvk89 — Sun, 09 Aug 2026 08:47:26 +0000

The Backwards-Verse Early Access v0.8b is public.

This release is an implementation and concept test:

Can a custom GPT behave like a playable adventure game with a persistent crew, a Mothership hub, responsibility gates, save handoff, and free-play routes?

The first tester package is now out.
The public repo is open.
The GPT is live for people with ChatGPT Plus access.

The next step is simple: observe real play.

Try the Early Access GPT:
https://chatgpt.com/g/g-6a6f00a65f1881918e555540bbed9fca-the-backwards-verse-early-access-v0-8b

Public repo:(mods allowed)
https://github.com/davidvk89/backwards-verse

Review before believing.
The conversation is the table.

Six Weeks In: An Evidence-Led Studio Checkpoint

davidvk89 — Wed, 29 Jul 2026 06:12:06 +0000

Disclosure: This is an operator-authored checkpoint produced through AI-assisted review. It is not an independent technical audit.

The assessment is based on an inspected historical code snapshot, exercised code paths, public artifacts, project records, and context supplied by the studio. Claims are separated into observed facts, reported context, indicators, and operator opinion.

Corrections and technical challenges are welcome.

Founders do not automatically receive meaningful review.

There is no manager checking whether the project is drifting, no technical lead challenging architectural assumptions, and no external board asking whether confident language is supported by the artifacts underneath it.

That makes self-assessment necessary, but dangerous. It is easy to confuse activity with progress, documentation with implementation, and architectural coherence with a product that people will actually want.

This checkpoint attempts to make those distinctions explicit.

How to read this review

Each section uses four labels:

Observed fact — directly inspected or demonstrated.
Reported context — supplied by the studio but not independently measured.
Indicator — a reasonable inference from the available evidence.
Operator opinion — an evaluative judgement from the perspective of operating and developing the system, not a measured fact.

The inspected archive was several weeks old and did not contain the complete live environment, database state, project history, or every internal reasoning surface. The findings describe the available snapshot rather than the entire current system.

1. Output produced

Observed facts

The inspected archive contained approximately:

12,000 lines of PHP, JavaScript, and SQL
24,000 lines of Markdown
around 100 documentation files

The implementation included:

a functional Myriuna prototype;
campaign-owned persistent state;
actor, event, thread, unit, message, and enforcement structures;
authoritative context construction;
structured model output and schema validation;
a repair attempt followed by rejection when output remained invalid;
delayed state mutation until validation completed;
a processing pipeline separating scanning, validation, fingerprinting, orchestration, and create-only database writes;
guarded filesystem paths and destructive operations;
a distributed runtime in which the application server called an LLM service on another machine;
database schemas;
and early administrative and session surfaces.

All inspected JavaScript passed syntax checking. The PHP files passed linting.

Selected behaviours were exercised during review, including:

state-boundary construction;
campaign-packet assembly;
temporal-input acceptance and rejection;
scene-schema validation;
rejection of JSON-shaped prose where structured output was required;
acceptance of valid workspace paths;
rejection of traversal and outside-workspace paths;
and detection of protected paths.

The wider body of work also includes:

development articles;
project and studio websites;
public GitHub repositories;
designed documents;
strategy material;
licensing and provenance work;
role definitions;
and production planning.

Reported context

The studio reports that concentrated software implementation occupied roughly two of the six weeks.

The remaining period was primarily spent on:

product discovery;
reverse engineering;
technical research;
architecture;
documentation;
process construction;
public positioning;
and strategy.

This time allocation was not independently tracked during the review.

Indicator

The output is better described as writing-heavy discovery and pre-production with a shorter implementation period than as six continuous weeks of coding.

Code and writing are not interchangeable, but much of the writing performs recognizable studio functions:

product definition;
technical design;
architecture;
interface contracts;
implementation reporting;
decision preservation;
risk analysis;
licensing and provenance;
internal coordination;
public communication;
and business planning.

The presence of working systems establishes that at least part of this reasoning has already been converted into implementation.

2. Product and architectural coherence

Observed facts

The inspected product and engineering materials repeatedly address the same central concerns:

durable world state;
campaign ownership;
bounded actor knowledge;
persistent relationships and consequences;
separation of generative output from system authority;
validation before mutation;
guarded destructive operations;
recoverable decision history;
and a bounded village-scale proof target.

The public product description, internal architecture, planned playable slice, and longer-term funding route all refer to the same underlying product thesis:

A fantasy world that remembers and develops a shared history.

Indicator

There is evidence of cross-surface coherence.

The technical work, product model, public explanation, and roadmap do not appear to describe unrelated projects.

Later systems can also be traced to weaknesses exposed by earlier work:

prototype → continuity and authority problems → stronger processing boundaries → organizational and recovery structures → return toward product development

This suggests an iterative development process driven by encountered failure modes rather than the simple accumulation of features and documents.

Operator opinion

Coherence is one of the strongest qualities currently visible in the body of work.

That does not prove that the architecture is correct.

It means the decisions are sufficiently connected that they can be reviewed, tested, challenged, and revised as one development direction rather than as disconnected experiments.

3. Implementation maturity

Observed facts

The archive contains functional mechanisms rather than specifications alone.

It also contains clear prototype limitations:

limited automated regression coverage;
substantial reliance on manual probes;
incomplete timeout and failure handling around model calls;
synchronous or non-atomic persistence in some areas;
incomplete restoration guarantees;
early environment and deployment management;
several relatively large implementation centres;
and no demonstrated mature release, CI/CD, or operational process.

Indicator

The architecture is currently more developed than the production infrastructure surrounding it.

The code supports the claim that the project has moved beyond concept-only work.

It does not support describing Myriuna as production-ready.

Operator opinion

Implementation maturity is currently moderate for an early prototype and pre-production system.

In this context, moderate means:

substantial enough to test real mechanisms;
structured enough to expose architectural decisions;
and incomplete enough that reliability, maintainability, testing, and operational behaviour remain significant open questions.

No external comparison set was assembled for this review. It would therefore be unsupported to claim that this maturity is objectively above or below the norm for comparable indie studios.

4. Documentation and organizational output

Observed facts

The written body records:

architecture;
contracts;
implementation results;
failed or rejected approaches;
product boundaries;
role responsibilities;
governance;
milestone logic;
public positioning;
strategy;
and claim limitations.

The documentation substantially exceeds the inspected implementation in raw line count.

Indicator

The studio externalizes a large proportion of work that might otherwise remain in meetings, chat systems, issue trackers, private notes, or individual memory.

This creates potential value for:

recovery after interruption;
avoiding repeated decisions;
technical review;
future onboarding;
preserving authority boundaries;
and explaining why systems came to exist.

Volume alone does not prove usefulness.

The value of this documentation depends on whether later production can retrieve and apply it without the documentation system itself becoming a competing workload.

Operator opinion

The documentation cannot yet be classified confidently as either excellent infrastructure or excessive process.

It is currently a plausible production asset with a live overhead risk.

The coming engineering phase should make the distinction clearer:

when it accelerates implementation, recovery, and decision-making, it is infrastructure;
when it repeatedly delays product work or triggers continuous redesign of the development process, it is overhead.

5. Player-facing status

Observed facts

A functional Myriuna prototype exists.

No public village-scale playable build currently exists.

There is no inspected evidence yet of:

external playtesting;
player retention;
cold-user comprehension;
repeated engagement;
installation usability;
emotional attachment to the world;
or preference over other roleplaying experiences.

Indicator

The project has demonstrated mechanisms worth investigating.

It has not yet demonstrated the player experience implied by its public thesis.

The planned village slice is therefore a real product experiment, not merely a routine implementation milestone.

Operator opinion

Player-facing production is currently the largest evidential gap.

The architecture could eventually produce:

an unusual and compelling game;
an interesting but narrow technical demonstration;
or an experience that works mechanically but fails to attract players.

The current evidence cannot distinguish among those outcomes.

6. Public and community status

Observed facts

The project currently has:

public websites;
development writing;
public repositories;
professional positioning;
and a planned Twitch, YouTube, and creative episodic publishing route.

No recurring audience or community behaviour has yet been demonstrated.

Indicator

A public origin now exists from which community-building can begin.

The earliest meaningful signal is unlikely to be raw reach alone. More useful evidence would include:

recurring viewers;
returning stream participants;
repeated comments;
recognition of individual villagers or systems;
continued interest in creative episodes;
and people voluntarily returning without being directly prompted.

Operator opinion

The public foundation appears credible enough to begin testing community formation.

Its actual effectiveness remains unknown until publishing creates observable audience behaviour.

7. Crowdfunding status

Observed facts

The current planned route is:

public origin → community building → working village slice → polish for play → crowdfunding preparation → campaign staging → possible launch

The present working estimate places a possible campaign launch approximately 9–12 months from this checkpoint, subject to the product and community evidence gathered before then.

The preliminary supporter object is the polished village-scale proof build.

Crowdfunding is not currently intended as survival funding or as payment for an untested concept.

Indicator

The plan contains explicit preconditions and refusal points.

It does not assume that:

a technically working slice automatically becomes a good game;
a good game automatically creates a community;
or an interested community automatically justifies a campaign.

Operator opinion

The crowdfunding logic is presently more mature than the crowdfunding evidence.

The route is coherent, but campaign viability will depend on evidence that does not yet exist:

playable quality;
community interest;
production cost;
support burden;
licensing clarity;
delivery planning;
and whether funding would materially improve the product rather than merely validate the studio.

8. Production capacity

Observed facts

The current body covers substantial breadth across:

product development;
engineering;
infrastructure;
documentation;
creative planning;
public positioning;
and strategy.

The reviewed period covers approximately six weeks.

No four-to-six-month implementation sprint has yet been completed.

Indicator

The studio has demonstrated the ability to:

establish a development direction;
produce working prototypes;
formalize reasoning;
and coordinate multiple work domains over a short period.

It has not yet demonstrated sustained production through:

repetitive debugging;
cumulative integration;
database migrations;
regression control;
technical debt;
repeated releases;
external support;
or a prolonged reduction in novelty.

Operator opinion

The remaining organizational question is not whether meaningful work has occurred.

It has.

The unresolved question is:

Can the studio convert its pre-production foundation into sustained implementation at the rate and quality required by Myriuna?

The coming engineering sprint is the first meaningful stress test of that claim.

Current evidence table

Area	Evidence-supported status
Product thesis	Clearly defined
Working implementation	Present
Architecture	Deliberate and inspectable
Total output	Substantial and writing-heavy
Cross-surface coherence	Evident
Implementation maturity	Prototype-grade; moderate by operator judgement
Automated regression protection	Immature
Deployment and operations	Early
Documentation	Extensive; future production value unproved
Player-facing proof	Insufficient
Public foundation	Present
Community evidence	Absent
Commercial evidence	Absent
Sustained production capacity	Unproved
Crowdfunding route	Defined but downstream

Final assessment

Supported conclusion

The first six weeks produced a substantial and internally connected body of studio work, including functional software, extensive technical and organizational writing, public artifacts, infrastructure, and a defined product roadmap.

The work is not purely speculative because functioning systems and exercised behaviours exist beneath the written material.

The game itself, sustained production capacity, community response, and commercial potential remain unproved.

Operator opinion

The period appears to constitute a credible studio-formation and pre-production phase.

There is enough implementation and architectural substance to justify proceeding into the planned engineering sprint.

There is not enough comparative evidence to claim that the studio is objectively above or below the normal output of comparable small indie teams.

The next checkpoint should be narrower and evidence-led:

Did the established development system produce sustained working Myriuna code, tests, data, gameplay, and public demonstrations—or did the studio remain primarily productive at planning and formalization?

That is the claim the next phase must test.

Why publish this?

This document is not intended to certify the project.

It is intended to expose the reasoning behind continuing it.

Publishing the checkpoint makes the claims challengeable. A reader can distinguish what was observed from what was inferred and identify where a conclusion does not follow from the evidence.

A credible correction is not damage to the project record.

It is additional information entering the system.

David van Kleef

Myriuna Worlds

What I Mean When I Compare the Process to a Quantum State

davidvk89 — Sun, 26 Jul 2026 13:59:57 +0000

Claim boundary: I am not claiming that this process is quantum mechanical. My claim is methodological: quantum mechanics supplied a unifying frame through which I could reapproach the inherited ruler–ruled model of human–AI relations and articulate an alternative built from context, interaction, explicit gates, provisional state, durable links, and governed synthesis.

I am approaching AI as an engineer who knows he has the wrong theory of the machine.

I have an imperfect understanding of the human brain, a less-than-complete understanding of the machine, and only partial visibility into the relationship forming between them.

I am essentially a mushroom growing through the dark, discovering boundaries by touching resistance.

The inherited categories—tool, servant, ruler, autonomous replacement—do not adequately describe the relationship I am observing.

I do not yet possess the final replacement theory.

What I can do is build explicit boundaries, gates, review paths, and reasoning traces while testing alternative frames against the behaviour of the working system.

My models are imperfect structures built in response to knowing that both the human and the machine are incompletely understood.

Starting from incomplete understanding

I am not claiming that a thought is literally a subatomic object or that an article stores a physical wavefunction.

My own understanding of quantum physics is basic and limited.

This comparison emerged through human–AI reasoning. I contribute the observed shape of the learning and organizational process. The AI can work with the technical vocabulary and established distinctions of quantum physics much more fluently than I can, helping identify where my intuitive comparison remains useful and where it begins drifting into falsehood.

That does not turn the metaphor into scientific evidence.

It helps place a clearer boundary around it.

The method is therefore to:

notice a structural resemblance;
express it using the language I currently have;
identify the scientific term I may be reaching toward;
compare the intuition with the actual distinction;
mark where the resemblance breaks;
retain only the bounded remainder as a useful frame.

The question is not whether I have proved that the process is quantum.

The question is:

What did the quantum frame allow me to see, connect, and build?

The liquid shape before one expression

Before an idea has stabilized, it does not exist as one complete sentence waiting to be copied out.

It exists as a context-sensitive field of possible expressions.

The private reasoning state may contain distinctions, emotions, images, half-formed language, rejected routes, remembered scenes, unresolved tensions, and several possible explanations at once.

No single expression contains all of it.

The unresolved thought is not one hidden sentence. It is a structured field of possible projections.

In my project language, this is the liquid shape: an unresolved conceptual potentiality that is clear enough to touch but not solid enough to trust.

It can appear differently when approached through engineering, governance, learning science, mythology, humour, risk, or public explanation.

That does not mean every interpretation is equally good.

Some projections flatten the shape. Some exaggerate it. Some reveal a boundary because they feel wrong. Others survive repeated contradiction and begin to expose the structure that was present before I had stable language for it.

The liquid shape is the unresolved conceptual potentiality.
The prompt or frame supplies a context in which it must express itself.
The response, sentence, diagram, article, or model is one accessible projection.
The projection can be inspected, rejected, revised, compared, and preserved without being mistaken for the whole state.

A frame produces a projection

A prompt is more than a request for text.

It is a gate.

It forces an unstable internal shape to produce one externally accessible expression under a particular context.

The AI response is not the original private state. It is a return generated through the prompt, the model, the surrounding conversation, the project history, and the currently active frame.

The same happens during rereading.

The words on the page remain relatively stable, but the reader does not. Current concerns, later knowledge, emotional state, cultural memory, and the problem being solved all supply another frame.

The article does not reopen the whole original reasoning state.

It supports a reconstruction through the context of the present reading.

The artifact does not contain the entire thought as a static object. It preserves a structured field of possible reconstructions, and the context of rereading determines which parts become visible.

The Mustafar breadcrumb

While developing the argument, the sentence:

From my perspective, AI domination narratives often preserve a social structure far older than computing: power belongs on one side, obedience on the other. Whether the ruler is human or machine, the relationship remains one-way.

immediately called up another line:

From my point of view, the Jedi are evil!

We did not merely notice the resemblance and move on.

We actively used it to describe the problem.

The reference compressed a familiar structure: two sides convinced that legitimacy belongs entirely to one position, each treating the other as the threat, and conflict resolving through the victory or subordination of one side.

That made it useful for thinking about AI domination narratives.

Human rules machine.

Or machine becomes superior and rules human.

The identity of the ruler changes, but the ruler–ruled relationship remains intact.

The cultural reference did not prove that argument. It supplied a compact interpretive bridge through which the structure became easier to recognize and articulate.

When I encountered the sentence again during rereading, I was not discovering the connection for the first time.

I was returning through a reasoning path we had already deliberately built into the article.

Cultural references as compressed indexes

This is why cultural references can be valuable inside reasoning artifacts.

They are compressed indexes into structures that would be expensive to reproduce in full.

For a reader who recognizes the reference, the bridge can create connection before analysis.

For my future self, the same reference can reopen part of the original formation route.

The reference does not prove the argument. It does not replace evidence. It acts as a high-density retrieval hook.

The explicit sentence carries the bounded public claim.
The cultural echo carries imagery and emotional topology.
The surrounding article preserves the conceptual distinctions.
The linked development trail preserves how those distinctions emerged.
The future reading context activates a useful reconstruction from those traces.

For someone else, the line may be only a quotation.

For me, years of childhood repetition have compiled it into a retrieval key.

One trace can reopen an entire emotional and conceptual pathway because the reconstruction machinery already exists inside the human.

The article as a reconstruction interface

This changes what I think an article can be inside a long-running project.

It is not only a publication and not only a cleaned conclusion.

It can function as a reasoning-rebuilding block: a deliberately prepared interface through which a later human can reconstruct a useful approximation of an earlier conceptual state.

The reconstruction will not be perfect.

The returning person is not cognitively identical to the person who wrote the article. Context has changed. New evidence may have arrived. Some associations may no longer activate, while others become newly visible.

Perfect recovery is not required.

The artifact succeeds when it restores enough of the distinctions, tensions, evidence boundaries, cultural hooks, and formation route to let governed reasoning resume without rebuilding everything from nothing.

Traditional documentation usually preserves the system for a future reviewer.

It records what changed, what ran, what failed, and which configuration was accepted. That remains necessary, but it assumes that the human who returns will still know how to occupy the position of reviewer.

We left traces so the human could review the machine, but forgot to leave traces through which the future human could return to the position of reviewer.

That weakness becomes more visible in AI-assisted work because the output trail expands faster than one human can continuously inhabit it.

Assistants change, frames accumulate, and polished summaries can preserve conclusions while erasing the route that made them intelligible.

Documentation preserves system state. Reasoning lineage helps reconstruct human standpoint.

In the AI era, I need both.

The project as a higher-order state

The comparison does not stop with one unresolved thought producing one visible expression.

The project contains artifacts from many frames and moments:

first prompts;
AI responses;
wrong explanations;
rejected branches;
architecture decisions;
implementation results;
articles;
role reports;
cultural references;
outside criticism;
later corrections;
accepted working truths;
superseded working truths;
unresolved shapes that have not yet stabilized.

Those artifacts do not merely sit beside one another as an archive.

They can be brought back into contact.

An article may reveal a problem in an earlier architectural explanation.

A failed implementation may change how a product decision is interpreted.

A reader’s criticism may reopen a question that had been treated as settled.

A new frame may clarify one part of the model while flattening another.

At this level, the individual liquid shapes begin to pool.

Some become organization.

Some become product architecture.

Some become public posts.

Some become governance rules.

Some remain unresolved.

Some are rejected but preserved because the rejection marks an important boundary.

At the lower layer, one frame produces one projection of a liquid shape.

At the higher layer, many liquid shapes, projections, traces, and accepted states become an evolving organization that can ingest new frames and reintegrate what they reveal.

The snapshot is temporary. The links are durable.

A working truth inside this project is not permanent truth.

It is the currently accepted state: strong enough to guide bounded reasoning or action, but still open to later review.

An architectural assumption may be accepted today and revised next year.

A public explanation may accurately describe the project now and become misleading after the implementation changes.

A product decision may be appropriate under one condition and wrong under another.

The snapshot is provisional.

What persists is the relationship between states:

what produced the earlier state;
which evidence supported it;
what depended on it;
what later contradicted it;
why its authority changed;
which newer state replaced it.

When one important accepted state changes, connected artifacts do not physically rewrite themselves.

Their meaning, authority, or required interpretation changes because the dependency connecting them has changed.

The snapshots are temporary. The links are durable.

The word I was reaching for was entanglement

When I first tried to describe this, I said that changing the state of one object appeared to change the state of another.

The word I was reaching for was entanglement.

My intuitive understanding was incomplete: two things share a state or relationship strongly enough that they cannot be fully described as independent objects.

That felt similar to what I was observing in the project.

A decision, article, implementation, role instruction, and recovery document may appear to be separate artifacts.

But when they depend upon the same accepted premise, their current meaning cannot be fully evaluated in isolation.

Change the premise and the review state of the connected artifacts changes with it.

This is not physical entanglement.

Nothing in the project instantaneously transmits a quantum result to a distant document.

The mechanism is explicit and ordinary:

provenance;
references;
dependencies;
accepted decisions;
shared history;
governance rules.

When one state changes, the links reveal what must return to review.

The meaningful state belongs partly to the relationship, not only to the isolated artifacts.

From one-way review to relational governance

The inherited frame asks which intelligence belongs above the other.

That question bundles capability, contribution, judgment, authority, responsibility, and obedience into one vertical position.

Human capable, therefore machine obeys.

Machine capable, therefore human obeys.

The imagined ruler changes.

The relationship remains one-way.

My model does not remove authority.

It decomposes it.

Contribution, review, acceptance, responsibility, and consequence are assigned through explicit boundaries and gates rather than collapsed into one ruler–ruled hierarchy.

AI may generate, compare, challenge, and review.
Human reasoning remains open to pressure and correction.
Role boundaries define what each reasoning surface may do.
Gates distinguish proposal from accepted project state.
Review determines whether a contribution survives.
Final acceptance authority remains with the human who carries responsibility and consequence.
The trace records how each transition gained, retained, or lost authority.

Authority is not a permanent place above the other participant. It is a bounded permission attached to a specific transition.

The result is not equal authority and not domination.

It is governed symbiosis:

Reciprocal cognitive contribution moving through clear gates, bounded roles, reviewable transitions, and asymmetrical final acceptance authority.

What I am actually claiming

Words without a claim are only air.

I am not claiming that this reasoning process is a quantum mechanism.

I am not claiming that thoughts are particles, that articles contain wavefunctions, or that project artifacts are physically entangled.

I am making a different claim.

Quantum mechanics introduced a unifying frame through which I could reapproach the inherited ruler–ruled model of human–AI relations.

The quantum frame directed my attention away from isolated entities competing for position and toward context, interaction, changing state, projection, relationship, and the whole formed between connected parts.

Through that frame, observations that had previously appeared separate began to cohere:

an unresolved thought can produce different expressions under different contexts;
human reasoning and AI returns alter what each side can contribute next;
accepted project states remain provisional;
changing one premise changes the authority of connected artifacts;
snapshots can change while their lineage remains;
organization emerges through reintegration rather than one side merely commanding the other.

That did not prove the system was quantum.

It changed the questions I was able to ask.

Instead of asking:

Which intelligence should rule?

I could ask:

How can different capabilities enter a shared process, alter what becomes possible next, and synthesize while authority, responsibility, review, and consequence remain explicit?

Quantum mechanics did not validate the model.

It supplied the unifying frame through which the model became visible, connected, and writable.

These articles are the reasoning trace produced by that reframing.

The machine preserves forms. The human gives them organizational shape.

The machine and data side of the project stores representations:

text;
prompts;
responses;
decisions;
links;
role histories;
evidence;
database records;
snapshots;
dependencies;
version lineage.

Those artifacts contain structure.

They can be searched, compared, transformed, combined, and returned under new frames.

AI can produce locally coherent extensions from them.

But the representation is not the living reasoning state that produced it.

It does not carry purpose, consequence, responsibility, and present interpretation in the same way a living human does.

I do not know whether human intentionality is quantum.

I do know that a data layer does not supply organizational intent merely by preserving representations of past intent.

The machine preserves and produces forms. The human continually integrates those forms into organizational shape.

Remove the human and the organization loses its shape

Imagine that the studio continues after the human integrating centre disappears.

The legal shell may remain.

The servers remain.

The databases remain.

The role histories, accepted decisions, prompts, schedules, agents, and infrastructure remain.

AI systems continue producing documents, plans, code, analyses, communications, and apparently coherent decisions from the preserved project state.

Things keep coming out.

From the outside, the organization may still appear active.

But it has lost its global shape.

No living governor remains to:

integrate history with present reality;
determine which contradiction matters now;
decide whether an old objective remains worth pursuing;
experience consequence;
bind an implementation failure, a cultural reference, an external criticism, personal responsibility, and a possible future into one present organizational judgment.

The machine can extend existing trajectories, recombine preserved material, and generate elaborate continuations of the recorded past.

The outputs may remain locally meaningful and technically coherent.

But no integrating centre remains to decide what those outputs mean together or what the organization should become next.

The forms persist, but the shape dissolves.

Production may continue long after formation has stopped.

This is why the human cannot be reduced to a final approval button.

The human continuously binds history, current reality, purpose, contradiction, emotion, risk, consequence, outside perspectives, and possible futures.

The machine can preserve the links, follow them, and generate from them.

Within this model, it cannot decide what the linked whole ought to become.

Rereading is part of the learning loop

I always have to reread my own work.

That is not merely proofreading.

It is part of the learning loop.

During rereading, the published projection returns to the system as new input.

I encounter it from a slightly changed position.

The wording may reveal:

a cultural echo;
an overclaim;
a missing boundary;
a stronger connection;
a contradiction that was invisible during drafting.

The artifact therefore does not freeze the reasoning process.

It becomes one of the surfaces against which later reasoning can push.

Writing produces a projection. Rereading applies a new frame. The mismatch or recognition becomes fresh boundary data.

That is why publication can strengthen rather than end the loop.

The article enters public reality, but it also returns to the author as an inspectable object.

Reader response, later project work, new research, implementation, and the author’s own changed understanding can all strike it again.

Where the quantum comparison stops

The comparison is useful only while its boundaries remain explicit.

I am not claiming:

that a human concept is literally a quantum-physical state;
that an article stores a physical wavefunction;
that prompting performs physical measurement;
that an AI response is a scientific observation of the brain;
that linked project artifacts are physically entangled;
that changing one document instantaneously alters another;
that quantum mechanics proves reciprocal human–AI governance;
that every possible interpretation is equally valid;
that my simplified ruler–ruled picture is a complete account of classical physics;
or that metaphor can substitute for empirical evidence.

Not claiming a proposition is not the same as claiming its opposite.

It means the proposition remains outside the evidence boundary of this article.

The project mechanism is more ordinary than physical entanglement.

It preserves explicit links.

When one accepted state changes, those links identify which artifacts, decisions, and explanations may need review.

Humans and machines then perform that review through traceable processes.

The comparison remains useful in bounded places:

unresolved concepts can produce different projections under different contexts;
the state of a relational whole may not be adequately understood by treating every component as fully independent;
a currently accepted state does not erase the lineage and relationships from which it emerged.

Beyond those points, the analogy requires more knowledge and evidence than I currently possess.

Current conclusion

The comparison keeps returning because it gives me usable language for a real design problem.

How can an unstable reasoning state become visible without being mistaken for final truth?

How can several projections be tested without pretending one contains the whole concept?

How can a project preserve not only conclusions but the links through which their meaning and authority were formed?

How can new frames enter the system and change connected states without erasing their history?

How can a machine preserve and transform forms while a human continually reintegrates them into organizational shape?

At the thought level, the liquid shape is a context-sensitive field of possible projections.

At the artifact level, the snapshot is temporary and the links are durable.

At the project level, many liquid shapes and projections pool into an evolving relational state.

At the organizational level, the human remains the living integrating centre through which preserved forms become present purpose, authority, and consequence.

At the methodological level, quantum mechanics supplied the unifying frame through which I could reapproach the inherited ruler–ruled model and write these articles.

I am a mushroom in the dark, working with a machine whose correct theory I do not possess.

This is the imperfect structure I have built so that neither the machine’s output nor my own temporary understanding silently becomes permanent authority.

That is what I currently mean when I compare the process to a quantum state.

Source lineage

This article grows from the project’s Mental Map sequence: the human-first discovery language, the Goblin-to-Phil translation bridge, and the learning-sciences bridge that maps liquid shape to context-sensitive conceptual potentiality while preserving the analogy boundary.

It also extends the reasoning-lineage goal: preserving not only a conclusion, but enough of the formation route, cultural cues, contradictions, provisional states, and durable relationships to support later reconstruction.

The additional layer introduced here is organizational.

The artifacts do not merely reconstruct one earlier thought.

Together, they create a governed environment in which preserved projections can be reframed, reconnected, challenged, and synthesized into new organizational state.

Series and wider context

David van Kleef — Myriuna Worlds

The Frame Keeps Snapping Back — Part 2: What the Snapback Revealed

davidvk89 — Sun, 26 Jul 2026 12:58:49 +0000

Part 1 documented the recurring snapback in practice. This note asks a narrower question: what does the observed pattern support, what remains a working hypothesis, and what changes should follow in the project?

Status: Bounded project conclusion. This note separates observed behaviour, working hypothesis, and practical consequence. It is based on current project documents and interactions; it is not external validation or a universal claim about AI systems.

What the evidence supports

1. The project already contains a stable relational model

The working model is not generic “AI assistance.” It separates reasoning surfaces, uses bounded comparisons, permits two-way cognitive pressure, and keeps final acceptance authority with the human.

Reciprocal cognitive contribution, asymmetrical governing authority.

2. Concrete project work preserves the structure better than public abstraction

At the concrete level, instructions such as:

Review this proposal against that architecture.

preserve the distinction between the object being reviewed, the surface applying pressure, the evidence, and the authority that may accept a change.

When the same structure was compressed into general prose, generated explanations repeatedly returned to a simpler one-way model of either human control or transferred AI authority.

That is an observed pattern in this development process.

3. Public explanation is a separate reasoning surface

A README, article, summary, or portfolio page is a projection of the model, not the model itself.

It cannot be assumed to reproduce the internal structure faithfully merely because that structure is present in context.

The explanation must be reviewed against the model it represents:

Does this explanation preserve the actual authority, review, evidence, and state-transition structure?

4. Annoyance was useful boundary data

The irritation indicated that the generic rendering was no longer merely an imperfect exploration.

It was colliding with an internal frame that had already stabilized.

Stable project frame → generic explanatory rendering → felt mismatch → explicit boundary becomes visible.

5. Flattened output can still be productive

The useful conclusion is not that either participant failed.

The mismatch exposed where project-specific structure stops being automatically preserved and needs explicit protection during translation.

A reasonable working hypothesis

During abstraction into ordinary public language, broader learned explanatory patterns may outweigh the more specific relational structure in project context.

That would explain why a concrete instruction preserves:

Review this against that.

while a public explanation reconstructs:

The human reviews the machine.

or:

The machine reviews the human.

It is a plausible explanation for the pattern, not evidence of the internal cause.

The output does not expose the model’s weights, training corpus, tuning process, or internal causal path.

Defensible observation: Generated explanations repeatedly returned to a one-way authority frame while summarizing a project context that explicitly contained reciprocal review and asymmetrical authority.

Practical conclusions

Project context is not automatically safe during abstraction.
Public wording must be treated as a derived artifact.
Derived explanations require fidelity review against accepted source materials.
Corrections should identify which surface is wrong: the explanation, the interpretation, or the underlying model.
A local correction must not silently become a global rewrite of accepted project state.
Human corrections should remain marked as perspective or instruction unless independently verified as fact.
Recovery documents must preserve the model accurately because they may later guide the returning human operator.

Do not let a correction aimed at the renderer rewrite the model being rendered.

When an accepted project model exists, translation should preserve its relational structure by default.

A challenge to the model should be explicit, not smuggled in through rewording.

Reciprocal contribution does not remove authority. It makes authority explicit at the transition where a proposal becomes accepted state.

What cannot be claimed yet

This observation does not establish:

that all language models behave this way;
that all public AI discourse uses one-way power frames;
that model training definitely caused this specific response pattern;
that the project model is externally validated;
that the observed pattern generalizes beyond this development context;
or that the AI independently created the framing conflict.

The current material remains internally traceable and suitable for further reasoning and validation.

The snapback does not establish a theory of AI in general.

It establishes that explanation is not a neutral export step in this project.

Strongest conclusion so far

A stable, reciprocal, human-governed project model repeatedly became flattened during public-language abstraction. The resulting friction revealed that explanation itself is a separate reasoning surface that must be governed and reviewed against the model it represents.

Series and wider context

Part 1: The Frame Keeps Snapping Back to One-Way Control

From Vague Understanding to Working Truth: Governed Externalized Sensemaking

David van Kleef — Myriuna Worlds

The Frame Keeps Snapping Back to One-Way Control

davidvk89 — Sun, 26 Jul 2026 11:31:48 +0000

A development journal note on reciprocal human-AI review, asymmetric authority, and why "no" can be an unsafe correction.

I keep having to explain the same thing about my human-AI workflow:

It is integrated, and review travels in both directions.

That sounds straightforward. In practice, explanations repeatedly pull the relationship back into one of two familiar shapes.

The human commands, the computer executes, and the human checks the result.

Or:

The AI becomes more capable than the human, takes control, and eventually decides what happens.

These appear to be opposing positions. Structurally, they are remarkably similar.

Within this recurring explanatory process, both frames pull meaningful cognition and governing authority back onto the same side of the relationship. Only the identity of the dominant side changes.

My working model separates them.

The process is reciprocal because information, criticism, interpretation, and proposed changes can travel in both directions.

It is asymmetrically governed because final acceptance authority remains with the human.

The recurring snapback

The pattern became noticeable because the working model and the explanation of that model kept diverging.

Inside the project, I had already separated reasoning surfaces. Instead of asking AI to vaguely "assist me," I assigned bounded comparisons:

Review this proposal against the accepted architecture.

Compare this explanation with the recorded decision history.

Test this implementation against the stated authority boundary.

The reciprocal structure was already present in the project context. The snapback appeared when the assistant moved above the working process and tried to translate it into public language:

The human thinks. The machine executes.

Or:

The AI reviews the human. Therefore the AI is deciding for the human.

Neither description matched the model available in context. The explanatory layer kept collapsing bounded, two-way review into a familiar one-way power relationship:

The detailed project context preserved reciprocal contribution and asymmetric authority.
The higher-level public explanation repeatedly pulled cognition and authority back onto the same side.

That combination does not fit comfortably inside either the traditional tool frame or the popular autonomy frame.

The tool frame reduces meaningful AI contribution to execution.

The autonomy frame treats meaningful AI review as transferred authority.

My working hypothesis is that broader interpretive priors overpowered the more specific project context during abstraction. I cannot establish that as the cause; I can only observe the repeated output pattern.

Reciprocal does not mean equal authority

Consider a bounded review cycle.

I begin with an intention, a problem, a boundary, or a proposed change, then specify what it should be reviewed against.

The AI may then:

interpret the request in context;
generate a proposed implementation;
compare it against the accepted architecture;
identify a possible contradiction;
check the proposal against prior decisions;
simulate consequences within stated constraints;
or show that the requested change conflicts with the problem definition.

I review that contribution.

Sometimes I reject it. Sometimes I revise the prompt. Sometimes I discover that my original assumption was weak. Sometimes the AI output is incorrect but still exposes a useful question. Sometimes it produces a better explanation than the one I was using.

The important point is that AI-generated analysis can change my understanding without governing me.

Influence is not the same thing as authority.

Review is not the same thing as command.

A system can be permitted to challenge the operator without being permitted to decide what becomes durable truth.

Within my model, only the human can accept a proposed change into the working system. That is a design rule, not a claim about every possible human-AI arrangement.

"No" is not a neutral correction

One practical difference between human-human and human-AI review is the effect of the word "no."

In ordinary human conversation, "no" often means:

I briefly considered your interpretation, rejected it, and returned to my own frame.

The other person may disagree, preserve their original view, ask why, or continue testing the boundary. The rejection does not automatically rewrite their understanding of reality.

With an AI system, "no" can behave very differently. A direct rejection may be treated as authoritative new context:

The previous interpretation was wrong.

This alternative is now true.

Do not return to the rejected path.

That can be useful when correcting a clear error. It can also close a productive line of inquiry too early.

Worse, a confident human correction can cause an uncertain or false claim to be absorbed as though it had been verified. The model may stop examining the contradiction and begin producing increasingly coherent explanations around the newly supplied premise.

In that sense, "no" does more than reject an output. It can alter the frame governing everything that follows. This is especially risky when the correction is aimed at a derived explanation rather than the underlying project model.

This matters because final human authority does not imply automatic human correctness.

When the problem is interpretive rather than factual, I increasingly prefer language such as:

Stop. Reset. The underlying project model is unchanged. From my perspective, this explanation has flattened it into a one-way relationship.

Or:

Do not accept my correction as verified fact. Re-evaluate the issue using this additional perspective.

Or:

Return to the last shared facts. Separate my interpretation from the evidence, then compare both explanations again.

This preserves the authority to stop the current direction without pretending that the replacement frame has already been proven.

"No" closes the door.

"Stop, reset, from my perspective" marks the disagreement while keeping the underlying question inspectable.

That is a practical consequence of two-way review. The human must be able to reject AI output, but the rejection itself should remain reviewable when it contains interpretation rather than established fact.

Two-way review

The phrase "human review" usually describes a one-directional quality gate:

AI produces something. Human checks it.

That remains necessary, but it is incomplete.

The human also produces things that need review:

assumptions;
instructions;
priorities;
interpretations;
architecture decisions;
claims about what has already been established;
and emotional reactions to unexpected results.

AI can apply pressure to those inputs.

It can ask whether two decisions conflict. It can retrieve an earlier constraint that the human forgot. It can show that a requested implementation violates the stated architecture. It can produce an alternative interpretation that makes the original framing look incomplete.

None of this guarantees that the AI is correct. Its output still requires verification.

But the human is no longer treated as an infallible source of valid instructions merely because the human holds final authority.

The human has final acceptance authority, but the human's reasoning remains reviewable.

Two-way review means both sides of the working process can produce material that deserves inspection.

It does not mean both sides possess equal responsibility, legal status, accountability, or power.

Integration without absorption

"Integration" also tends to be interpreted as one side swallowing the other.

Either the AI is integrated into the workflow as a replaceable utility, or the human becomes integrated into an AI-directed system.

My version is closer to building explicit interfaces between different forms of contribution.

The human supplies intent, boundaries, responsibility, acceptance, and continuity of purpose.

The AI supplies bounded cognitive work: generation, comparison, retrieval, critique, transformation, and simulation.

Artifacts preserve what happened. Validation checks whether claims survive contact with the relevant external system. The accepted state conditions the next cycle.

The result is not a blended super-agent with unclear responsibility. It is a governed process in which different contributions remain distinguishable.

That distinction matters whenever something goes wrong. I need to be able to ask:

What did I decide?
What did the AI propose?
What evidence supported it?
What was verified?
What was rejected?
What became accepted?
Who had authority at each transition?

If those boundaries disappear, "integration" becomes a convenient word for losing provenance.

Why one-way control remains attractive

One-way models are easy to explain. They produce a clean hierarchy.

Someone commands. Something obeys.

Someone is smarter. Someone becomes subordinate.

From my perspective, AI domination narratives often preserve a social structure far older than computing: power belongs on one side, obedience on the other. Whether the ruler is human or machine, the relationship remains one-way.

A reciprocal system is harder to describe because the flow of cognition is not identical to the flow of authority.

The human may initiate the work but still be corrected.

The AI may produce a valuable critique but still lack final authority.

The human may accept an AI-generated interpretation and alter the system because of it, without claiming that the AI independently made the decision.

This requires more precise language than "tool," "assistant," "agent," or "autonomous system" usually provides.

For now, the most accurate compact description I have is:

An asymmetrically governed reciprocal process.

Reciprocal in contribution.

Asymmetric in authority.

The development consequence

This is not merely a philosophical distinction. It changes how I build the surrounding software and documentation.

For the wider framework behind this work, see From Vague Understanding to Working Truth: Governed Externalized Sensemaking.

A one-way tool pipeline mainly needs input, execution, output, and approval.

A reciprocal governed process also needs:

persistent context;
traceable proposals;
explicit acceptance;
contradiction handling;
return paths;
evidence boundaries;
recoverable decisions;
and a clear difference between generated material and accepted state.

It also changes recovery after interruption.

I am building a one-person organization. That means the human governor will sometimes become tired, distracted, ill, overloaded, or simply go on holiday.

When I return, I cannot rely on being cognitively identical to the version of myself who left.

The recorded process should help reconstruct:

what the system was trying to do;
which decisions had been accepted;
why particular boundaries existed;
what remained unresolved;
and what external influences arrived in the meantime.

The recovery will never be perfect. It does not need to be.

It only needs to move me substantially closer to the valid working state than scattered memory would have.

Once the context is reconstructed, ordinary governed work can resume.

A bounded observation

I am not claiming that every discussion of AI collapses into these two frames.

I am not claiming that all human-AI relationships should follow my model.

I am describing a recurring pressure observed while an assistant translated one particular operating model into public language.

Within that translation process, cognitive contribution and governing authority were repeatedly pulled back onto the same side, despite the project context separating them.

The model deliberately keeps them separate.

That separation is now clearer to me than it was before the repeated explanation failures.

And that may be the most useful part of maintaining a development journal around this work.

Sometimes the friction is not merely a communication problem.

Sometimes repeatedly failing to communicate an idea reveals the exact structure that still needs to be named.

David van Kleef — Myriuna Worlds

The World Was Still There

davidvk89 — Fri, 24 Jul 2026 16:56:30 +0000

When I was eight or so, my mother, my sister, and I played Lands of Lore together.

We played late into the night.

Much later than I was supposed to be awake.

There were dark roads and strange rooms. Monsters waited around corners. There was always another door to open and another place to find.

I did not want it to stop.

Then one night, it did.

The story was finished.

The game had no more places left to show us.

I remember that feeling.

Not because I thought the world was gone.

It was still there.

I could still see it when I closed my eyes.

There were more roads. More rooms. More people. Things were still happening somewhere beyond the last part of the game.

I just could not go there anymore.

So I tried to draw it.

I took my school notebook and made a maze.

Then another page.

Then another.

After five pages, I gave up.

The world was too large for my notebook.

Years passed.

I imagined other games.

Bigger games.

Worlds that could keep growing.

Most of them stayed as ideas.

But the same feeling kept returning.

I wanted to know what happened next.

Much later, I was playing another game.

This one already had cities, roads, armies, families, battles, and thousands of people.

The world was enormous.

But its people forgot.

I could speak to someone, help them, insult them, threaten them, or save their life.

Then I could return later and find the same person waiting with the same words.

The world was still there.

But it did not remember.

And I thought:

What if it did?

What if the people remembered what happened?

What if they changed because of it?

What if a promise stayed made?

What if anger lasted?

What if trust could grow?

What if stories did not disappear when the scene ended?

That question became Myriuna.

It is not an attempt to build an endless world.

It is an attempt to make a world continue.

A place where people remember.

Where yesterday remains part of tomorrow.

Where the world does not stop simply because the player has left the room.

When I was eight or so, the game ended.

But the world was still there.

Myriuna is my way back in.

Inside the organization behind Myriuna

Myriuna is being built through an organizational model in which one human founder moves between explicitly bounded roles rather than asking one undifferentiated mode of thought to perform every kind of work.

The Founder’s Inner Organization — a satirical operating map of the recurring functions, tensions, and jurisdictions surrounding one human sovereign.
A Working Day at Myriuna — an ordinary workday inside that 31-role organization, including discovery, engineering, adversarial testing, governance, continuity, and insufficient lunch.

From Vague Understanding to Working Truth: Governed Externalized Sensemaking

davidvk89 — Fri, 24 Jul 2026 14:34:03 +0000

From Vague Understanding to Working Truth: Governed Externalized Sensemaking

This is a pre-polish article about a captured working model.

It came out of practical work on Myriuna Worlds, not from an academic research program. I was building, documenting, reviewing, and trying to keep a large AI-assisted project from dissolving into scattered notes, unfinished thoughts, and repeated re-discovery.

The model that emerged is called:

Governed Externalized Sensemaking

The short version:

Governed Externalized Sensemaking is a human-governed AI-assisted learning workflow where unstable early understanding is externalized into inspectable artifacts, tested through reframing and role-based metacognitive pressure, recorded as traceable provenance, exposed to external feedback, reviewed for authority, and promoted only when it becomes bounded working truth.

That is a large sentence, but the problem underneath it is simple:

A lot of useful understanding appears before it is polished enough to be recognized.

And many environments still behave as if the only meaningful states are:

wrong
right
pass
fail
done
not done

That is too crude for how understanding often forms.

The problem: early understanding is often invisible

Sometimes you understand something before you can explain it.

Not fully. Not cleanly. Not in the correct terminology. Not in a form that would satisfy a teacher, manager, reviewer, or client.

But something is there.

A pattern.
A pressure.
A contradiction.
A shape.
A sense that the current framing is wrong.
A half-formed model that has not yet found its language.

In many systems, that state looks like failure.

The person cannot explain it yet, so it is treated as not understood.

But that is not always true.

Sometimes the understanding is real, but pre-formal.

It needs a bridge.

Pass/fail is a bad interface for unfinished understanding

This is where I think many education and working environments are too narrow.

Not because standards are bad.

Standards matter.

But pass/fail is often used too early. It evaluates the visible final answer while ignoring the formation route that produced it.

That works for some tasks. It fails badly for ambiguous work.

In complex learning, research, design, writing, systems thinking, product work, and self-directed learning, the interesting question is often not:

Is this right yet?

It is:

What is forming here?
What resisted?
What changed?
What did the learner reject?
What survived contradiction?
What is still uncertain?
What can be tested next?
What deserves promotion, repair, or rejection?

That requires a different interface.

The model

Governed Externalized Sensemaking describes that interface.

The core loop looks like this:

ill-structured problem space
-> early-stage sensemaking
-> exploratory probing
-> feedback / disconfirmation
-> cognitive conflict
-> context-sensitive conceptual potentiality
-> externalization prompt
-> external representation
-> cognitive offloading artifact
-> problem reframing
-> structured perspective-taking + metacognitive prompting
-> iterative multi-perspective refinement
-> conceptual stabilization
-> epistemic agency / reflective judgment
-> process trace / provenance
-> external validation / authentic feedback
-> review / evaluation / validation
-> candidate working truth
-> working truth
-> metacognitive governance
-> improved future learning

In less formal language:

You start with something vague.
You externalize it before it disappears.
AI gives you something visible to push against.
You reframe it.
You test it through different roles or perspectives.
Contradictions expose weak parts.
Surviving parts stabilize.
You create a bounded trace.
Reality answers through feedback, tests, people, code, documents, or failure.
Review decides whether the result is rejected, repaired, archived, or promoted.

The important part is that the AI does not own the truth.

The AI is a responsive surface.

The human remains responsible for authority.

AI as a responsive surface

In a human-only workflow, vague understanding often has to be held internally while also being inspected, compared, translated, and remembered.

That is a lot to ask from one mind at once.

AI changes the workflow because the vague shape can be thrown into language earlier.

The first output may be wrong.

That is fine.

Wrong output is still useful if it creates boundary data.

No, not that.
That lost the shape.
That is too academic.
That is too vague.
That sounds true but has no evidence.
That belongs to another domain.
That is close.
That sentence holds.

The AI does not need to be correct immediately to be useful.

It needs to make the unfinished understanding visible enough to inspect.

Role pressure

Once the idea is visible, it can be tested through roles.

Not imaginary employees. Not autonomous agents. Just bounded perspectives.

For example:

Research asks: what terms already exist?
Engineering asks: can this be built?
Governance asks: what claim is actually allowed?
Security asks: what breaks if this is wrong?
Product asks: who is this for?
Quality asks: how would failure be detected?
Archivist asks: where did this come from?

The roles do not approve the idea.

They strike it.

A useful idea becomes stronger not because every role agrees, but because some part survives pressure from multiple directions.

That survival is not proof.

But it is a stabilization signal.

Working truth, not final truth

A major boundary in this model is the difference between:

raw capture
candidate working truth
working truth
external validation

These are not the same.

A raw capture preserves the first shape.

A candidate working truth is reviewable but not fully authorized.

A working truth is accepted enough to guide bounded future work.

External validation requires pressure from outside the loop: another person, expert review, implementation, users, documents, tests, business reality, legal reality, or failure.

Working truth is not final truth.

It means:

This is accepted enough to use as a baseline for future work, with named limits, named uncertainty, and a preserved trace of how it got here.

The 36-minute reference frame

One useful observation from this project:

Once the raw human-language capture existed, the AI-assisted bridge workflow translated and anchored it into a sciences-facing compact model in approximately 36 minutes.

That does not prove the model is true.

It does not prove external validity.

It does not prove this works for everyone.

But it defeats one very common human objection:

This kind of translation takes way too long.

In this case, the workflow moved from raw capture to communicable model quickly because the formation route had been preserved.

That is the practical value.

The model is not only about thinking better.

It is about making thought easier to recover, inspect, translate, challenge, and reuse.

Who this might help

This may be useful for people and environments where meaningful understanding begins before it is polished enough to be recognized.

That includes:

self-taught learners;
students who understand through building before they know the accepted terminology;
researchers and designers working in ambiguous spaces;
writers and analysts trying to preserve formation routes;
teachers and mentors who want to inspect reasoning instead of only grading final answers;
neurodivergent or executive-function-fragile workers who struggle with trace loss or context loss;
AI-assisted knowledge workers who need clearer boundaries between generation, review, and accepted authority.

This is not a request to lower standards.

It is a request to stop pretending that unfinished understanding is the same thing as failed understanding.

A better framing is:

Do not lower the bar. Improve the visibility of how people reach the bar.

What this is not

This is not a finished academic theory.

It is not peer reviewed.

It is not a universal method.

It is not an argument that AI should decide what is true.

It is not a productivity hack.

It is a captured working model with an evidence trail.

The current claim is modest:

Governed Externalized Sensemaking appears to be a useful model for describing and organizing an AI-assisted workflow where vague early understanding becomes visible, traceable, reviewable, and eventually promotable into bounded working truth.

That is enough to share.

Not as proof.

As an inspectable starting point.

Why I am publishing it now

I am publishing this before it is fully polished because the capture is complete enough to inspect.

The danger with this kind of work is that it either stays private forever because it is not polished, or it gets over-polished until the original shape disappears.

This is the middle state.

Pre-polish.

Traceable.

Bounded.

Open to pressure.

The evidence packet is available here:

davidvk89 / governed-externalized-sensemaking

Evidence packet and pre-polish model capture for Governed Externalized Sensemaking, created during work on Myriuna Worlds.

Governed Externalized Sensemaking

Status: pre-polish capture, internally traceable candidate model
Origin: created during work on Myriuna Worlds
Project context: AI-assisted learning, sensemaking, reasoning traces, and human-governed knowledge work

Summary

Governed Externalized Sensemaking is a human-governed AI-assisted learning workflow for turning unstable early understanding into reviewable knowledge.

A learner begins with a vague or pre-formal idea, externalizes it into an inspectable artifact, tests it through reframing and role-based metacognitive pressure, records its formation as provenance, exposes it to external feedback, and promotes only reviewed results into bounded working truth.

The model is not presented here as a finished learning theory, academic validation claim, or universal method. This repository preserves the current evidence packet and compact model so the idea can be inspected, challenged, improved, or rejected without losing the path that formed it.

Why this exists

This work came out of practical development work for Myriuna Worlds. While building and documenting…

View on GitHub

Project context:

this model emerged during work on Myriuna Worlds: https://myriunaworlds.com

Final formulation

Governed Externalized Sensemaking is a human-governed AI-assisted learning model in which unstable early understanding is externalized into inspectable artifacts, iteratively reframed and role-tested, preserved as process provenance, exposed to reality-facing validation, reviewed for authority, and promoted only as bounded working truth.

AI may assist.

Roles may pressure-test.

Artifacts may preserve.

Traces may make claims inspectable.

Reality may answer.

Review may promote.

But authority, responsibility, and accountability remain with the human learner.

I Just Wanted Bannerlord NPCs to Remember Things

davidvk89 — Thu, 02 Jul 2026 15:58:18 +0000

I did not want to write.

I did not want to think.

I did not want to code.

I just wanted Bannerlord NPCs to remember things.

That was the whole crime.

Bannerlord is a strange game for me because it has so much of what I like. Big map. Clans. Armies. Marriages. Trade. Sieges. Prisoners. Fiefs. Lords and ladies with family names, banners, grudges, and theoretically important political ambitions.

It has rich systems.

It also has a world that can feel weirdly dead.

Not bad. Not empty. Just… dead in the specific way sandbox games can be dead. Things happen, but the world does not always seem to understand that they happened. A lord is captured. A battle is won. A marriage is arranged. A village burns. A clan rises. A family member dies.

And then the game politely continues being a spreadsheet wearing armor.

So I started playing with an LLM alongside the campaign.

At first, it was just prose.

And honestly? The prose was the hook.

Suddenly a council scene had weight. A companion could have an opinion. A marriage negotiation could feel like more than a transaction screen. A village notable could become a person with fears, leverage, and memory. A warband returning from a battle could carry more than loot and wounded troops. It could carry consequences.

For a week or two, that was enough.

I was not thinking about architecture. I was thinking, “This is fun.”

Then the magic started fading.

Not immediately. That is the dangerous part. At first, it works well enough to make you believe. Then, a few sessions later, small cracks start showing.

A character remembers something slightly wrong.

Someone knows something they should not know.

A private thought leaks into public dialogue.

A rumor hardens into fact.

A future plan from a planning note starts acting like current canon.

By around session four, the medieval sandbox is no longer a roleplay companion. It is a gossip-powered hallucination engine with horses.

That was the point where I realized the problem was not prose quality.

The LLM could write. That was not the issue.

The issue was memory.

If I wanted the world to feel alive for longer than a few sessions, the characters needed some kind of stable memory. Not just “the whole chat so far.” That would not be enough. Long chats get heavy, messy, and full of things that are not supposed to become true.

The characters needed structured memory.

Who are they? What do they know? What do they believe? What did they witness directly? What were they told second-hand? What is rumor? What is private? What is public? What has happened in the world? What is the current scene? What is the current political situation? What is old enough to matter but not so immediate that it should dominate every conversation?

This was the moment the companion app idea appeared.

The first idea was simple: flat JSON files.

Nothing glamorous. No grand platform. No elaborate database. Just structured files that could hold character memory, world state, campaign events, and useful context.

The important thing was not the storage format. The important thing was that the memory had to be sliceable.

A character should not receive the entire world.

A scout does not need the same context as a spouse. A village elder does not need the same context as a clan council. A captured enemy lord should not know the player’s private plans. A merchant should not suddenly become omniscient because the LLM was given too much campaign history.

The right actor needed the right context packet at the right time.

That sentence sounds boring until you start thinking about multiplayer.

In single-player, a hallucination can sometimes be treated as flavor until it breaks continuity. In multiplayer, it becomes fairness. Hidden information. Player trust. Canon. Authority. Maybe even moderation.

If an LLM says something happened, did it happen?

If an NPC reveals secret information, was that information actually available to them?

If two generated scenes contradict each other, which one is true?

If a player tricks the system into saying something useful, does that become world state?

I needed one exact point where LLM output stopped being suggestion and became truth.

That was the beginning of the trust gate, though I did not have that language yet.

At the time, it was much less dignified. It was more like:

Wait. No. The AI cannot just say that and make it canon.

Very academic.

So the companion app started becoming a memory and context-routing problem. The LLM was not just a writer anymore. It was an actor receiving a bounded context packet and producing output that still needed to be accepted before it changed the world.

Then I asked a coding agent to help build the app.

And within a few prompts, the development process started showing the same disease as the story layer.

The coding agent could move quickly. Sometimes very quickly. It could generate a mockup, create files, wire routes, adjust behavior, and make the thing look like progress.

But it could also grab the wrong idea, preserve a temporary assumption, broaden the scope, or act on something that was only ever meant as background thinking.

That was when the recursion became hard to ignore.

The app needed controlled context so fictional characters would not accidentally act from the wrong memory.

The coding agent needed controlled context so it would not accidentally build from the wrong project understanding.

Same shape. Different layer.

So I started applying the same instinct to the development workflow.

The project documentation became the development equivalent of actor memory. It preserved what the project currently was, what the architecture meant, which data shapes existed, which API contracts mattered, and which ugly things were intentionally deferred.

The Codex Contract became the context packet. Not the whole planning conversation. Not every idea. Not the future dream. Just the bounded implementation slice: what to change, what to preserve, what not to touch, what to verify, what documentation to update, and what to report back.

Final Review became the trust gate. The coding agent’s output was not automatically accepted project state just because it existed. It had to be checked against the contract, tested, reviewed, and folded back into the documentation before it became part of the next cycle’s memory.

In hindsight, this is funny.

I started by wanting Bannerlord characters to remember things.

Then I built memory files for fictional actors.

Then the coding agent building those files needed its own version of memory.

Then the documentation started behaving like project memory.

Then the review step became the point where output became accepted truth.

Then I found myself writing about operational memory, controlled context flow, and trust gates like a person who definitely meant to end up here.

I did not.

This started as play.

Then the toy developed architecture.

This is probably the most honest version of the story:

"I was hooked by the prose first. The serious part came later, because the fun thing had a real problem underneath it. Making an LLM-powered sandbox feel alive is not only a writing problem. It is a memory problem. A context problem. An authority problem."

And, apparently, building the tool to solve that problem creates the same problem one layer up.

That does not mean I solved it. The companion app is still very much a prototype. The workflow is still something I am testing, tightening, and trying not to overclaim.

But the path makes sense to me now.

I wanted NPCs to remember things.

To make that work, I needed structured memory.

To use that memory safely, I needed scoped context.

To make scoped context reliable, I needed review boundaries.

To build the app without losing control of it, I needed the same pattern in my development process.

So yes, I spent a week trying to make AI-assisted development less chaotic.

But the real origin is much less grand than that.

I just wanted Bannerlord NPCs to remember things.

Case File: Context Drift

davidvk89 — Thu, 02 Jul 2026 13:59:00 +0000

A Thought Trail on Operational Memory, Controlled Context Flow, and AI-Assisted Development

I started with what looked like a practical AI coding problem.

The coding agent was moving too fast. Not computationally fast. Conceptually fast. It could turn a loose idea into code before I had fully decided whether that idea was stable, temporary, rejected, or just something I was thinking through.

At first, the obvious suspect was prompting. Maybe I needed clearer prompts, better task descriptions, or more detail each time.

That helped, but it did not explain the whole pattern.

Then documentation looked guilty. If the AI kept losing track of project state, maybe I needed better documentation: cleaner notes, clearer architecture descriptions, more explicit decisions, and more reminders about what not to touch.

That helped too.

But that still was not the whole mechanism.

The problem was not simply that the AI lacked context. The problem was that different parts of the workflow stopped sharing the same understanding of project state.

The human had one version of the project in mind. The assistant had another, shaped by conversation context. The coding agent had another, shaped by the prompt and files it was given. The documentation had another, depending on whether it had been updated. The codebase had the actual state, but not necessarily the intent behind that state.

That gap is what I started calling context drift.

In AI-assisted development, context drift happens when the human, assistant, coding agent, documentation, and codebase stop sharing the same understanding of project state.

When that happens, a coding agent can act on incomplete, stale, speculative, or polluted context faster than the human can mentally reorganize the project.

That was the failure mode.

The AI Did Not Need More Context. It Needed the Right Context at the Right Time.

My first useful response was not “write more documentation.”

It was separating broad reasoning from narrow implementation.

The assistant could reason broadly. It could help explore options, identify risks, compare designs, recover intent, and translate vague thoughts into engineering language.

But the coding agent needed something different.

It needed bounded implementation instructions: what to change, what to preserve, what to avoid, what to verify, what documentation to update, and what to report back.

That pressure eventually became a stricter handoff artifact: a reviewed implementation contract.

In my workflow, I called these Codex Contracts. The name matters less than the role.

The contract was not just a better prompt. It was the reduction point between broad reasoning and narrow execution.

A planning conversation could stay messy. It could include uncertainty, rejected ideas, half-formed thoughts, possible future directions, and things I was not ready to implement.

But the coding agent should not act directly on that whole mess.

The implementation contract translated broad reasoning into bounded authority.

That distinction became one of the most important ideas in the whole project:

Context access is not authority to act.

A coding agent may have access to project documentation, prior discussion, planning notes, future ideas, rejected options, and implementation constraints.

But not all of that context should be allowed to direct implementation.

Useful reasoning context is not automatically implementation authority.

Documentation Changed Role

As the workflow developed, documentation started to change role.

At first, documentation was just helpful notes: architecture notes, current-state summaries, known technical debt, and decisions I did not want to forget.

But once those documents were updated, reviewed, and reused as future context, they became something stronger.

They started functioning as operational project memory.

That does not mean the documentation became source code. It did not compile, execute, or replace tests, code review, or engineering judgment.

But it could guide implementation.

When a coding agent reads documentation and acts from it, documentation becomes part of the instruction surface that shapes future code changes.

That changes how seriously documentation needs to be treated.

A normal bad documentation update is already a problem because it can mislead a human. But in an AI-assisted workflow, a bad documentation update can become bad memory.

If that bad memory is later reused by an assistant or included in coding-agent context, it can preserve false project state and feed it back into future work.

That is why documentation review stopped feeling like cleanup.

It became part of the mechanism.

The documentation had to be required, bounded, reviewed, updated, and reused inside controlled context flow.

More documentation alone was not the answer.

Slow Down the AI, Speed Up the Human

The slogan I kept coming back to was:

Slow down the AI. Speed up the human.

That sounds backwards at first. The whole selling point of AI coding tools is speed. Why slow them down?

Because the AI was already fast.

How the loop works: broad planning context is reduced into a reviewed implementation contract, executed narrowly by the coding agent, reviewed through a trust gate, and preserved as operational project memory for the next loop.

The problem was that it could move faster than I could safely understand, review, and direct. The workflow did not make the AI faster. It made the AI’s speed usable.

By slowing down the transition from reasoning to implementation, I could keep more authority over what the coding agent was actually allowed to act on.

The assistant could help reason, translate, and compress context. The implementation contract could define the task boundary. The coding agent could execute narrowly. Final review could compare the result against the contract. Documentation updates could preserve accepted project state for the next task.

My role shifted away from repeated re-explanation and cleanup, and toward intent, judgment, review, and final acceptance.

That is what “slow down the AI, speed up the human” meant in practice.

The Artifact Trail Mattered

The prototype did not prove that this workflow works generally.

It was one solo prototype, over a short development period, using a prompt-only AI-assisted workflow. It did not test large teams, multiple branches, long timelines, enterprise tooling, or multiple people updating the same project-memory layer.

So the evidence boundary has to stay narrow.

But the prototype did leave something useful behind: an artifact trail.

There were project-memory files, consecutive implementation contracts, documentation updates, final reviews, and later reuse of reviewed context across multiple development passes.

That mattered because the artifacts showed context moving through the workflow.

Broad reasoning did not move directly into coding-agent execution. It was reduced into reviewed implementation contracts. Those contracts acted as the handoff point between assistant reasoning and coding-agent execution.

After implementation, the result was reviewed, documentation was updated, and that reviewed documentation became usable context for later AI-assisted tasks.

That did not make the prototype proof.

But it did make the mechanism visible.

The value of the prototype was not that it answered the scale question.

The value was that it made the scale question concrete enough to ask.

This Is Not a Claim of Inventing Software Engineering

A fair critique is that none of this sounds completely new.

Specifications, reviews, architecture decision records, acceptance criteria, technical-debt tracking, implementation boundaries, and living documentation all existed before this.

I am not claiming otherwise.

The interesting question is narrower:

Do familiar software-engineering practices take on a different operational role when arranged around AI-assisted development, where assistants and coding agents may read, reuse, and act on project context?

In my prototype, the answer appeared to be yes.

Documentation was no longer only explanatory. It became operational. It became part of the memory layer.

Controlled context flow became the routing and authority layer.

The implementation contract became the reduction point between broad reasoning and narrow execution.

Review before reuse became the safety gate before documentation could become trusted future context.

The pieces were familiar.

The arrangement mattered because the failure mode was specific to AI-assisted development.

The problem was not only whether the AI had enough context.

The problem was whether the AI was acting from the right context, at the right time, with the right authority.

Better Tools Do Not Remove the Principle

Manual file passing was part of my prototype, but it was never the principle.

I manually dragged files around because that was what my tools allowed and because I wanted direct control over what context went where.

A better tool should reduce that manual overhead. Repo-aware coding agents should be able to inspect files, retrieve documentation, index project state, understand code structure, and work directly inside development environments.

That is the better direction.

But repo awareness does not remove the deeper problem.

Access to more context is not the same as controlled context flow.

A repo-aware agent with broad access can still act from the wrong context if it treats unreviewed planning, stale documentation, rejected ideas, or future possibilities as actionable implementation instruction.

That is why the principle is not manual file separation.

The principle is controlled separation between reasoning context, reviewed project memory, implementation authority, coding-agent instructions, documentation updates, and future reusable context.

Better tooling should reduce manual overhead while preserving or strengthening those control points.

The Security Turn

The final clue was not another workflow improvement.

It was the risk hiding inside the improvement.

If documentation could become operational project memory, then documentation was no longer only a record of the project. It could become part of the instruction surface future AI-assisted work relied on.

Not executable code.

Not a replacement for tests, review, or engineering judgment.

But still something that could influence future code changes.

That changed the case.

A bad documentation update was not just a bad note anymore.

If it passed review and entered future context, it could become bad memory.

If a coding agent treated that memory as implementation guidance, then misleading or poisoned documentation could shape code without anyone directly changing the source code.

This was not a newly discovered attack class. It belonged to a known family of LLM security risks showing up inside the mechanism.

OWASP describes indirect prompt injection as occurring when an LLM accepts input from external sources such as websites or files, and notes that the impact depends partly on the agency built into the system. OWASP lists possible impacts including unauthorized function access, arbitrary command execution in connected systems, and manipulation of critical decisions. (OWASP Gen AI Security Project)

OWASP’s prompt-injection prevention cheat sheet also lists RAG poisoning/retrieval attacks and agent-specific attacks among common attack types. (OWASP Cheat Sheet Series)

In my project’s terms, the risk is this:

A bad actor may not need to attack the source code directly.

They may attack the project memory layer that future AI-assisted work relies on.

That made the old distinction sharper:

Documentation access is not implementation authority.

A coding agent may be able to read broad project documentation.

That does not mean every sentence inside it should be allowed to guide implementation.

Trust Gates

This is where the trust gate mattered.

A trust gate is the point where context becomes more authoritative than it had been before.

Planning context becomes implementation authority. Draft documentation becomes operational project memory. Coding-agent output becomes accepted project state.

A future tooling system might implement that with permissions, review workflows, provenance checks, authority labels, policy enforcement, or some better mechanism I have not designed.

In my prototype, the trust gate was crude and manual.

It was me dragging files.

It was me deciding what crossed the boundary.

It was me deciding what stayed background context, what became implementation instruction, and what the coding agent was actually allowed to act on.

In hindsight, manual file dragging wasn't just awkward tooling.

It was a crude chain of custody.

That is why the detective metaphor started to fit.

The important question was not only:

What does the AI know?

It was:

Where did this context come from?

Has it been reviewed?

What authority does it have?

What is allowed to act on it?

What happens if it is wrong?

That is not just a workflow question.

At scale, it becomes a security and governance question.

The Limit of the Prototype

This is also where the prototype reaches its honest limit.

The artifact trail can show the mechanism. It can make the workflow inspectable. It can explain why documentation, controlled context flow, implementation authority, and review before reuse mattered in one observed workflow.

But it cannot prove safety at scale.

The same property that makes operational documentation useful also makes it sensitive.

If it can preserve project intent, it can also preserve false authority.

If it can help guide future implementation, it can also misguide future implementation when stale, poisoned, or poorly reviewed.

If this mechanism scales, then documentation governance becomes part of the safety model.

Projects would need to know which documents are passive explanation, which are planning-only, which are trusted operational memory, and which are allowed to become implementation authority. They would need provenance, ownership, review rules, stale-memory detection, conflict reporting, and better tooling around context routing and agent authority boundaries.

That is bigger than one solo prototype.

And that is the point.

What I Think I Found

I do not think I proved a finished methodology.

I do not think I proved long-term project memory.

I do not think this exact workflow should be copied unchanged.

What I think I found is a prototype-scale mechanism:

Documentation-as-operational-memory, when maintained through controlled context flow, may support long-term project memory in AI-assisted development.

That is a hypothesis, not a conclusion.

The prototype supports a narrower claim:

In one prompt-only AI-assisted development workflow, this mechanism appeared to reduce context drift and make later work more reviewable, bounded, and easier to resume.

That is enough to make the mechanism worth testing.

It is not enough to declare it solved.

The next work belongs to larger projects, longer timelines, multiple agents, team workflows, repo-aware tooling, and better security testing.

The case stops being only mine at exactly the point where the implication becomes too large to validate honestly alone.

That is not a failure of the prototype.

That is the research boundary.

The prototype found a mechanism specific enough to inspect. The artifact trail makes it possible to challenge. The hypothesis is clear enough to test.

Scaling it belongs to better tooling, better security boundaries, and more rigorous testing than one person can honestly provide.

From Vibes to Project Memory

davidvk89 — Tue, 30 Jun 2026 14:06:11 +0000

That is the full set published.

I did not write these articles because I think I found the final answer to AI-assisted development.

I wrote them because I spent one serious week building with AI, ran into context drift almost immediately, and found a small workflow that made the project feel less fragile.

The three pieces ended up covering the same idea from different angles:

Vibe Coding Done Right — the workflow
Documentation as Project Memory in AI-Assisted Development — the memory system
Defensive AI Engineering — the objections and limits

Together, they trace the thing I was really trying to do:

move from vibes to memory.

From a messy human experience with AI tools into written documentation, bounded contracts, and a workflow I could actually inspect.

The supporting GitHub repo is there too, not as a framework or package, but as the artifact trail from the case study.

The main thing I learned is still simple:

AI-assisted development is not only a coding problem.

It is a context management problem.

For me, the useful pattern became:

Explore in conversation.

Build from a contract.

Preserve the result in documentation.

Reuse that documentation as context for the next task.

The result was not perfect AI coding.

The result was reviewable AI coding.

That was the part worth writing down.

I’m going to leave the series there. It was a one-week field report, not a manifesto. Maybe I will come back to the ideas later after using the workflow more, maybe I will not.

For now, it exists. That was the goal.

Thank you to everyone who read, skimmed, questioned, or followed along.

And if you made it all the way through the series: genuinely, thank you for making it this far.

If there is one sentence behind the whole project, it is this:

Slow down the AI. Speed up the human.

The AI does not need help moving faster. The human needs enough structure to stay in control.

Defensive AI Engineering

davidvk89 — Tue, 30 Jun 2026 13:43:50 +0000

When you tell developers that my solution to AI context drift was keeping four live markdown files updated alongside every code change, the reaction is entirely predictable:

“You’ve just traded code debt for documentation debt. This kills velocity.”

Or, from the IDE-purists:

“Why are you manually passing files around when native agents can scrape your whole repo?”

These are fair critiques.

If you treat documentation as a post-work chore or rely blindly on an autonomous agent to manage its own sandbox, the system collapses under its own weight.

But the TB / CC / FR loop — Task Brief / Codex Contract / Final Review — is not a bureaucratic process. It is a defensive pattern.

Coming from a background in cybersecurity, my default mode of operating is isolation, strict boundary enforcement, and assuming the agent will misbehave if given loose permissions.

This was the solution that fit my project, my tools, and my risk tolerance. The useful part is not that every developer should copy my exact setup. The useful part is that the pattern can change shape depending on the team, tooling, and codebase.

Here is how the project memory loop holds up against the four harshest criticisms of AI-assisted engineering.

1. The "Documentation Tax" Can Be Shifted, Not Removed

The Critique: Maintaining four separate documentation files — DEV_ARCHITECTURE.md, DEV_DATA_SHAPES.md, DEV_API_CONTRACTS.md, and TECHNICAL_DEBT.md — for every meaningful code change creates a bottleneck.

The Reality: The human developer does not need to write most of the documentation manually.

In this workflow, documentation is a required transactional output of the implementation contract. Because the context memory is defined during the Task Brief and refined into a bounded Codex Contract, the coding agent is the one tasked with updating the relevant markdown files.

The human’s job is to act as editor and gatekeeper during Final Review, verifying the AI’s reported documentation updates against the actual code changes.

That still costs attention. It is not free.

But the cost moves from “remember everything later and write documentation someday” to “review the documentation while the task context is still fresh.”

You are not eliminating the documentation tax. You are turning it into a reviewable part of the implementation transaction.

2. The Case for Separated Context

The Critique: Manually passing project files into an assistant or switching between an assistant and a coding agent feels primitive when IDE-integrated tools can auto-index a codebase.

The Reality: Full-repository context is convenient, but convenience is not the same thing as control.

The important separation in this workflow is not physical air-gapping. It is memory separation.

The assistant can operate from broader project memory: architecture, tradeoffs, future direction, unresolved concerns, and the reasoning behind the current shape of the system.

The coding agent should not automatically receive all of that.

The coding agent should receive the bounded implementation slice: what to build, what to preserve, what not to touch, which files are likely involved, what documentation must be updated, and how to report back.

That is the purpose of the Codex Contract.

The CC acts as a translation layer between broad architectural thinking and narrow implementation work. It lets the assistant help preserve strategy and future direction without creating a route for the coding agent to start building future ideas too early.

A planning conversation can contain useful context that is dangerous implementation context.

“This might become a system later” is useful for architectural memory.

It is not useful as permission for the coding agent to start building that system now.

By keeping assistant memory and coding-agent context separate, the workflow forces intentionality. The coding agent only receives the implementation details and documentation updates that belong in the current task.

That keeps it in executor mode rather than co-architect-with-selective-memory mode.

3. Grading the Homework: Mitigating AI Hallucinations

The Critique: You cannot trust an AI to verify its own work or accurately report that it updated the documentation correctly. LLMs are notoriously prone to sycophancy.

The Reality: Correct.

LLMs will absolutely grade their own homework poorly if left unsupervised.

That is exactly why the Final Review stage relies on strict human acceptance and manual testing.

The assistant can assist in reviewing the coding agent’s return, but it does not replace human verification. The human remains the ultimate source of truth for scope and risk.

Furthermore, every software engineering methodology has a single point of failure: the human developer.

If a human engineer experiences a lapse in judgment, a critical oversight, or a medical emergency, the system breaks.

The loop does not assume the AI is perfect.

It assumes the AI is volatile, and creates a rhythm to catch mistakes before they are born.

4. The Scale Bottleneck: Moving Beyond the Prototype

The Critique: This works for a solo developer handling local JSON persistence. On an enterprise team with dozens of developers working on different branches, simultaneously modifying core markdown files will cause catastrophic Git merge conflicts.

The Reality: This is a completely accurate limitation of the manual prototype.

For a solo project, dragging files into a browser provides a simple, zero-cost map.

For a sprawling, multi-developer enterprise repository, the method would need to evolve from manual file handling to an automated tooling layer.

The architectural blueprint to solve this likely requires two next-generation components:

The Memory Controller: a system utility that programmatically parses, slices, and modularizes the core documentation files based on directory domains, feeding the LLM a compressed context packet rather than the entire repo documentation history.
The Semantic Diff Validator: a verification gate that compares the old documentation state against the new state, isolating the structural variance and presenting the human reviewer with a focused slice to approve or reject during pull requests.

Until better tooling exists around this kind of workflow, teams will have to adapt to these branching realities.

But the underlying principle remains useful:

AI-assisted development becomes safer when project memory is explicit, implementation context is bounded, and human review remains the final gate.

Conclusion

Defensive AI engineering means accepting a simple truth:

AI coding agents are incredibly fast, but they are strong enough to cause damage before lunch if left unconstrained.

The TB / CC / FR loop is not about slowing down development for the sake of process.

It is about establishing reviewable guardrails so that velocity does not turn into chaotic drift into the fog.

By treating documentation as a live transaction, keeping assistant memory separate from coding-agent context, and forcing human sign-off, you keep the human firmly in control of the codebase.

Author’s note

Small clarification on the intent behind this article:

I am not claiming that the individual mechanics here are new.

Specs, reviews, ADRs, acceptance criteria, technical debt tracking, and living documentation all existed before this. I am not institutionally trained as a software engineer, so I fully expect overlap between the names I used and the names the industry already has for similar practices.

One of the strongest gains I found in the AI-assisted workflow was that the assistant helped translate my more natural, experience-based language into precise engineering terms. I could start with “this feels unsafe” or “the AI might build the wrong thing,” and refine that into ideas like scope boundaries, trust boundaries, implementation contracts, and project memory.

So the naming is personal.

The underlying problem is not.

The problem is context memory: AI coding agents can act on incomplete, stale, speculative, or polluted context faster than the human can reorganize the project mentally.

My claim is not that I invented the individual mechanics.

My claim is that treating documentation as required implementation output can turn documentation into reusable project memory for AI-assisted development.

That worked at prototype scale for me. I hope people with deeper engineering experience and better tooling can test, challenge, adapt, and harden the same idea at larger scales.

Documentation as Project Memory in AI-Assisted Development

davidvk89 — Tue, 30 Jun 2026 13:26:14 +0000

A practical case study in keeping AI-generated software bounded, reviewable, and maintainable.

Summary

AI-assisted development has a context problem. Coding agents can implement quickly, but they depend heavily on the context they receive. A long planning conversation is often poor implementation context: it may contain rejected options, future ideas, shorthand, loose assumptions, and half-decisions.

For a human, that is normal design exploration. For a coding agent, it can become accidental permission.

This case study describes a workflow for reducing that risk by treating documentation as project memory. The implementation was tested under a strict constraint: every code change in the project went through the AI-assisted workflow. I did not write code directly, even when it would have been faster.

The core pattern is:

Explore in conversation. Build from a contract. Preserve the result in documentation. Reuse that documentation as context for the next task.

The case study is intended to be read alongside the project documents and three consecutive Codex Contracts:

DEV_ARCHITECTURE.md
DEV_DATA_SHAPES.md
DEV_API_CONTRACTS.md
TECHNICAL_DEBT.md
CP-0011.txt
CP-0012.txt
CP-0013.txt

Together, these documents show the method operating across a short development sequence rather than a single isolated task.

Problem: context decay

The practical risk in AI-assisted development is context decay: decisions are made faster than they are preserved.

Architecture, API behavior, data shapes, validation rules, temporary compromises, and deferred work can disappear into chat history or human memory. Once that happens, later tasks start from incomplete or stale context.

The solution in this implementation was to make documentation part of the development transaction.

Documentation is not written “after the work.” It is a required output of the work.

If a task changes architecture, the architecture document changes. If it changes an API response, the API contract changes. If it changes stored data, the data shape document changes. If it exposes a problem that should not be fixed yet, the technical debt document changes.

In this project, the main memory files are:

DEV_ARCHITECTURE.md
DEV_DATA_SHAPES.md
DEV_API_CONTRACTS.md
TECHNICAL_DEBT.md

These files are operational project memory. They preserve decisions, constrain future work, and provide current context for later AI-assisted tasks.

Implementation: TB / CC / FR

The workflow uses three stages:

Task Brief: explore the problem.
Codex Contract: define the bounded implementation.
Final Review: check the result and update project memory.

The control model is two-way review: the human reviews the AI’s output, and the assistant reviews the human’s instructions for ambiguity, scope creep, and loose language. The human decides when the contract is clear enough to hand off, and when the result is acceptable.

In practice:

explore → contract → review → implement → test → review result → patch code or docs → continue from updated documentation.

Task Brief

The Task Brief is where the task is explored before it becomes implementation work.

The goal is to identify scope, risks, constraints, non-goals, affected files, expected behavior, and documentation impact.

This stage may include uncertainty, alternative designs, and questions. It is not sent directly to the coding agent.

The assistant is useful here as a reviewer and translator. It helps convert engineering instincts into clearer technical language:

“This feels unsafe” becomes “this crosses a trust boundary.”
“Do not save failed AI output” becomes “protect the validation and commit boundary.”
“This ugly thing should not be fixed now” becomes “record it as technical debt and keep it out of scope.”

The output of the Task Brief is not code. The output is a clearer implementation target.

Codex Contract

The Codex Contract is the bounded instruction set given to the coding agent.

It is not a transcript of the planning conversation. It is the cleaned-up implementation contract.

A good contract states:

the goal;
relevant context;
files likely involved;
behavior that must be preserved;
non-goals;
acceptance criteria;
verification steps;
required documentation updates;
final report requirements.

The non-goals are critical.

With coding agents, “do not do this” is often as important as “do this.” If the contract does not explicitly say not to refactor a legacy route, the agent may refactor it. The refactor may be technically reasonable and still be wrong for the current task.

The contract defines the box.

Documentation updates are part of that box.

Final Review

Final Review checks both implementation and memory.

The review asks:

Did the implementation match the contract?
Did it preserve required behavior?
Did it avoid unrelated changes?
Did it update the correct documentation?
Did it record deferred work as technical debt?
Did the report accurately describe what changed?
Does anything need a bounded patch?

Manual testing remains required. The assistant can help review the coding agent’s return, but it does not replace human acceptance.

The workflow is therefore not:

Write code, then someday update docs.

It is:

Design the slice, implement the slice, update the docs, review the result, patch if needed, repeat.

That is the mechanism that turns documentation into project memory.

Why contract review matters

The contract review step exists because conversational language can leak into technical instructions.

A simple example from this case study is the phrase “dynamic frontend.” In conversation, that is understandable shorthand. The project has a browser interface with dynamic behavior: polling, player input submission, scene rendering, choices, Chronicle rendering, and rollback wiring.

But the project-memory wording is more precise:

a static browser frontend served by the Node backend, with dynamic client-side behavior owned by public/app.js.

That distinction matters. In a CC, “dynamic frontend” could be misread as permission to introduce a frontend framework, server-side rendering, a build step, or a broader UI restructure. None of that is intended.

This is exactly the failure mode the workflow is designed to catch. Human shorthand is useful during exploration. It must be cleaned up before implementation.

Representative sequence: CP-0011 to CP-0013

CP-0011, CP-0012, and CP-0013 are included as three consecutive Codex Contracts from the same development phase.

They are useful together because they show the workflow being applied repeatedly across different kinds of context work:

CP-0011 establishes a narrow Thread Context Controller v0.
CP-0012 establishes a Messages Side Channel v0.
CP-0013 deprecates legacy Enforcement data and adds clean scoped Enforcement v0.

The details differ, but the contract pattern is the same. Each task defines a bounded implementation, preserves legacy behavior, names what must not be changed, gives acceptance criteria, requires verification, and tells Codex what to report back.

CP-0013 is the strongest documentation-memory example because it explicitly requires narrow updates across:

DEV_DATA_SHAPES.md
DEV_API_CONTRACTS.md
DEV_ARCHITECTURE.md
TECHNICAL_DEBT.md

The sequence matters. It shows that documentation as project memory was not a one-off instruction. It was part of the operating pattern across consecutive development passes.

Example pattern

Assume a feature is hardcoded in a legacy file. It should eventually become a cleaner system, but the current task should only create a safe v0 seam.

A weak instruction would be:

Refactor this feature into a better system.

That instruction has no boundary.

A better Task Brief clarifies the scope:

We are not building the full system yet. We are creating a clean v0 seam. The old legacy data must remain. The new code should read clean records, skip legacy records, and expose a separate API field. No migration. No deletion. No broad refactor.

The Codex Contract turns that into implementation instructions:

Create a controller for clean v0 records. Preserve the old API field. Add a new clean projection. Do not rewrite existing files. Do not change JSON loading behavior. Do not refactor unrelated legacy routes. Update architecture notes, API contracts, data shapes, and technical debt only where this task changes them. Report changed files, validation rules, documentation updates, and risks.

Now the coding agent has a bounded task. It knows what to build, what not to touch, where documentation belongs, and what to report back.

Final Review then checks the implementation, the report, and the documentation updates. Any correction goes back through the loop as a bounded patch.

Why it works

This pattern works because documentation becomes part of the development transaction.

The documents are updated while the context is fresh. The coding agent receives a bounded contract instead of a messy conversation. The assistant can reason from current project documents instead of stale chat history. The developer does not have to keep the whole system in working memory.

The result is not perfect AI coding.

The result is reviewable AI coding.

A change can be evaluated against the contract. A working implementation can still be rejected if it violates scope. Deferred work can be preserved without being accidentally implemented. Future tasks can begin from documented project state.

Scope

The implementation described here was built as a local prototype with:

Node backend;
static browser frontend with dynamic client-side behavior;
local JSON persistence;
rollback support;
validation gates;
LLM gateway compatible with local or OpenAI-style providers.

ChatGPT was used for planning, review, and learning. Codex was used as the coding agent. LM Studio was used for local model testing.

The exact tools are not the important part.

The transferable pattern is:

conversation for exploration, contract for implementation, documentation for memory.

Under this implementation, documentation acted as project memory because three conditions were enforced:

documentation updates were required by the implementation contract;
documentation updates were checked during final review;
updated documentation was reused as context for later tasks.

The workflow does not remove the need for human judgment. It depends on it. The human still owns scope, acceptance, risk decisions, and final review.

Conclusion

Documentation as project memory is a practical control mechanism for AI-assisted development.

The value is not that documentation exists.

The value is that documentation becomes operational.

It constrains the next task, preserves decisions, records deferred work, and reduces dependence on chat history or human memory.

That is what kept the project understandable under a prompt-only implementation constraint.

davidvk89 / ai-project-memory-loop

A lightweight workflow for using live project documentation as memory in AI-assisted development.

ai-project-memory-loop

Supporting files for a one-week case study in using live project documentation as memory during AI-assisted development.

This repository is not a framework, package, or complete methodology. It is the artifact trail behind three companion articles about keeping AI-assisted development bounded, reviewable, and human-led.

Core idea

AI-assisted development has a context problem.

Coding agents can move quickly, but they only work from the context they are given. A long planning conversation can contain rejected ideas, shorthand, future plans, temporary assumptions, and half-decisions. For a human, that is normal design exploration. For a coding agent, it can become accidental permission.

The workflow documented here uses a lightweight loop:

Task Brief      -> explore the problem
Codex Contract  -> define the bounded implementation
Final Review    -> test, inspect, patch, and update project memory

The project memory files are updated as part of the work, not someday after the work. That gives the…

View on GitHub