06

Article 6 of 12 · ARTHA Craft

I Replaced My Entire Chat History With 5 Documents. Nothing Has Fallen Through the Cracks Since.

Not a wiki. Not a README. Five documents with specific jobs.

Jitander Singh Chauhan

Lead AI & Data Technologist · Haystream

At some point in every AI-assisted project, you hit the same wall.

You need to know what was built last week. You scroll back through chat history. You scan through sessions trying to find the decision. You piece together context from fragments of conversations that were never designed to be a record.

It works. Barely. Slowly. With no confidence that you found everything.

I spent weeks working that way. Then I stopped. Not because I found a better tool. Because I built a better system.

Five documents. Specific jobs. Nothing duplicated. Nothing missed.

And at the centre of all of it, one layer that makes the other four work.

Why Most Documentation Fails.

Before the system, let me explain why people try documentation and give up.

They build a wiki. It grows. Nobody maintains it. It gets stale. They stop trusting it. They go back to chat history. Or they build a README. It captures the starting state. The project evolves. The README doesn't. Six months later it describes a system that no longer exists.

The problem is not documentation. The problem is documentation without a job. [1]

Every document in this system has a job. A specific layer. A specific owner. A specific moment in the workflow where it is read, updated, and acted on. That is the difference between a wiki nobody trusts and a system that runs the project.

The Five Layers.

Layer1

The Constitution

What the platform is and what it cannot be. Non-negotiables governing every decision system-wide. Module inventory. Architectural boundaries. The first thing any agent reads. Changes rarely, and only with an explicit decision, never a casual edit.

ContextSeed.MD
Layer2

The Current State

What has been built recently. What is partially done. What is in progress right now. Not a history, a rolling snapshot. Keeps the constitution lean while capturing the living reality of where the product actually is today.

SecondaryContextFeed.MD
Layer3

The Session Bridge

Written at the end of every session. Read at the start of the next one. Exact stop point. Locked decisions. Open questions. Standing reminders. And a paste-ready prompt: the architect pastes it verbatim into a new chat. No typing. No improvising. No blank slate.

CONTEXT-HANDOFF.MD
Layer4

The Task Files

One document per feature. Background, design decisions, cross-layer dependencies, scope boundary, gap resolution, go-ahead prompt. The coding agent executes from this, not from memory, not from chat, not from an improvised brief. Written in the planning session, locked before the coding session opens.

STEP-XXXX-name.MD
Layer5

The Registers

Three live documents: bugs, enhancements, deployment issues. Nothing gets fixed without a register entry first. Nothing gets forgotten because it lived only in a chat. Every item has an ID, severity, status, and traceable path to resolution. Reviewed at every sprint start.

BUGS.MD · ENHANCEMENTS.MD · DEPLOYMENT-ISSUES.MD

Now: The Layer That Makes All the Others Work.

Every layer above is valuable on its own. But without one specific layer, they are five useful documents that don't quite form a system.

The Traceability Spine

The Step Sequence: REQCHAIN-STEP-SEQUENCE.MD

Every step ever designed lives here. Every step ever completed lives here. Status visible at a glance: done, in progress, pending design, blocked. History never lost: completed steps stay permanently. Nothing is ever removed.

But its job is bigger than a status tracker. Much bigger. The Step Sequence is the traceability spine of the entire methodology. Every other layer connects through it.

Planning Agent reads Step Sequence

Sees what has been built, what is planned, where the next feature fits. Designs from position, not from a blank slate.

Design work produces a Task File

Locked to a specific step ID. The ID is the traceability link: every decision traceable back to the step that created it.

Coding Agent executes against Task File

Builds from a locked brief. No design decisions to make. No gaps to fill. No invention required.

Step marked DONE. Handoff written.

History preserved. Context Handoff references the step ID. Next session opens, reads sequence, confirms position, picks up exactly.

This is traceability. Not as a compliance exercise. As a working practice. [2] Every decision, every feature, every fix: traceable. Not because you went looking for it. Because the system never lost it.

What This System Actually Gives You.

Before the system

  • New session starts with re-explaining
  • New developer starts with questions
  • New agent starts with assumptions
  • Decisions live in chat, or nowhere
  • Bugs fixed, refixed, unfixed
  • Speed without coherence

After the system

  • New session reads 5 docs, reports position, executes
  • New developer reads same 5 docs: zero questions
  • New agent gets consistent structured context every time
  • Every decision traceable to a step ID
  • Every bug has a register entry and a fix path
  • Speed with coherence

The speed does not come from the agent. [3] It comes from the system that feeds the agent. An agent with a clear, structured, complete brief moves faster and makes fewer mistakes than an agent trying to infer its brief from a chat history.

The reading order matters.

Constitution → Current State → Session Bridge → Step Sequence → Task File

Platform constraints before tactical instructions. An agent that reads the task file before the constitution will invent solutions that violate the architecture.

Five documents. Specific jobs. Connected by a traceability spine that never loses anything. That is the system.

Research & Further Reading

  • [1] Nygard, M., "Documenting Architecture Decisions", Cognitect Blog, 2011: Introduced Architecture Decision Records (ADRs) with the insight that documentation only survives when it has a specific, daily job. Endorsed by Martin Fowler (martinfowler.com, 2026). Industry Article
  • [2] Hutchins, E., Cognition in the Wild, MIT Press, 1995: Studied distributed cognition in naval navigation teams. Found that documents and artifacts are not aids to cognition. They are part of the cognitive system itself. The document system described here is a distributed cognitive architecture for human-AI teams. Book
  • [3] Forsgren, Humble & Kim, Accelerate: The Science of Lean Software and DevOps, IT Revolution Press, 2018: Based on 23,000+ data points from 2,000+ organizations, found that information flow and structured practices, not raw speed, predict software delivery performance. "High performers understand they don't have to trade speed for stability." Book

← Previous

Article 5

Next →

Article 7: This One Document Made It Surgical