The Model Already Read the README. MICA v0.1.8 Made It a Protocol
v0.1.7 made scoring a contract with fail-closed gates. v0.1.8 recognized that README-first behavior could serve as invocation — and formalized it as a schema-level protocol. This article uses simplified examples to show how the invocation gap that had existed since v0.0.1 was finally closed
Series
MICA SeriesPart 4 of 4
Glossary: terms used in this article
🔸 MICA (Memory Invocation & Context Archive): A governance schema for AI context management. Defines how context should be structured, trusted, scored, and handed off across sessions.
🔸 Fail-Closed Gate: An admission rule that excludes a context item if it fails a required threshold — regardless of its score on other dimensions. No exceptions. Introduced in v0.1.7.
🔸 README-as-Protocol: The pattern in which an AI session's natural behavior of reading the README first is formalized as the primary invocation mechanism. No installation required. Introduced in v0.1.8.
🔸 Invocation Protocol: The schema-level declaration of how a MICA archive reaches an AI session — and how the session confirms it was loaded. Formalized as a required field in v0.1.8.
🔸 Session Report Format: The structured opening report the model must produce at session start to confirm the archive was loaded. Required in v0.1.8.
🔸 Design Invariant Entry: A structured governance rule with identity, rule text, and severity. Replaced plain string invariants in v0.1.8.
🔸 Self-Test Policy: Machine-evaluable checks that validate the archive against the real project state — file existence, hash integrity, and README sync. Required in v0.1.8.
1. Where Part 3 Left Off
Part 3 covered v0.1.0 through v0.1.5.
By that point, the schema had become implementable, then auditable. Provenance gained a registry. Changes gained an audit trail. Invariants gained structure.
But two things still remained missing.
Scoring was still not structurally enforced at the schema level. The formula existed, but it was still closer to convention than contract.
And
invocation_protocol still did not exist. The archive could be perfectly governed — verified, logged, ruled — and the model could still begin work with no instruction to locate it.The governance was visible. It was not yet operative.
This part covers the versions that closed both gaps — and the observation that made the harder one easier to solve than expected.
2. v0.1.7: Scoring Becomes a Contract
Since v0.0.1, scoring had been one of the structurally weakest parts of MICA.
The earliest version used hardcoded test values with no defined combination rule. Later versions introduced an implementable formula, but the formula still lived as a declared behavior rather than a fully enforced contract. A conforming archive could still be structurally valid while leaving too much scoring behavior open to interpretation.
v0.1.7 changed that in two steps.
First, scoring became a structured policy.
Second, admission became fail-closed.
That second change matters more than it first appears.
A weighted score answers:
Which item ranks higher?
A fail-closed gate answers:
Should this item be considered at all?
That is the question Part 2 identified as missing from the usual output-reliability framing.
To illustrate the pattern, here is a simplified educational example:
This is not the production specification. It is a teaching example.
The point is simple: once admission becomes fail-closed, scoring stops being "rank everything and hope the top item is good enough." It becomes a governed decision boundary.
By v0.1.7, scoring had become a contract.
But scoring was never the deepest structural gap.
The deepest gap had always been invocation — how the archive reached the model at all.
3. The Observation That Changed the Question
Before v0.1.8, invocation was framed as an installation problem.
How do you make sure the model loads the archive before starting work?
The assumed answers were plugins, tools, configuration, or external services.
But that assumption missed something simpler.
In many repository-based AI sessions, the README is already the model's first orientation point. Not because it is explicitly configured to read it, but because it is the natural entry surface for understanding a workspace.
The invocation mechanism did not need to be invented.
It needed to be declared.
That insight changed the problem.
If the README is already where an AI session begins, then the README can carry a structured session protocol:
- load the archive
- run session-start checks
- report readiness
- stop if critical governance conditions fail
A simplified educational example looks like this:
This is the key idea behind README-as-Protocol.
The README is no longer just documentation.
It becomes the session entry layer.
README-as-Protocol is not a workaround.
It is a recognition: the invocation mechanism already existed in practice. It simply had not yet been formalized.
v0.1.8 turned that recognition into a schema-level contract.
4. v0.1.8: The Schema Reaches the Model
At this stage, the important change was not one field. It was the structural shift.
The archive no longer just described governance.
It declared how governance entered the session.
In simplified terms, v0.1.8 added five kinds of structure:
- the archive declares how it reaches the model
- the model must prove it loaded the archive
- invariants become structured governance objects
- the archive declares how drift is handled
- the archive can validate itself against the real project state
The following simplified example illustrates three of those five additions:
This example leaves out most of the real system. That is intentional.
The purpose is to show the architectural shift:
design_invariantssays what must remain true
invocation_protocolsays how the archive reaches the session
session_report_formatsays how the model proves it loaded the archive
The
id makes the invariant referenceable in audit output, and severity determines how violations are handled.Before v0.1.8, a session could begin with a perfectly governed archive existing somewhere in the repository — but with no requirement that the model actually load it.
After v0.1.8, the archive no longer merely existed.
It had a declared path into the session.
And the session was not considered ready until it reported that the archive had been loaded.
That is the moment where governance stopped being documentation and became runtime behavior.
Files change. Hashes drift. Before this layer existed, that drift could remain silent. Now the schema requires a declared response when the archive no longer matches the project it describes.
5. v0.1.8.1: Precision Patches
Once the major shift was in place, several smaller ambiguities appeared in practice.
These did not change the architecture.
They clarified how the architecture behaved.
In simplified terms, the patches did three things:
- they made self-tests more explicitly machine-evaluable
- they declared which runtime was responsible for running those tests
- they clarified authority between invariant definitions and derived track views so drift could be detected instead of silently accumulating
These are not the kinds of changes that make headlines.
They are the kinds of changes that make a governance system stable enough to survive repeated use.
That is what patch releases are for.
6. Playbook: What the Schema Cannot Enforce
At this point, a second document became necessary: the Playbook.
The schema can enforce structure:
- required fields
- valid shapes
- invocation declaration
- opening reports
- self-tests
- drift behavior
But it cannot enforce operator judgment:
- when to use which invocation pattern
- how to update invariants safely
- what counts as a complete archive
- which shortcuts are acceptable
- how to avoid human-caused drift
So the division became explicit.
The schema enforces structure. The Playbook enforces judgment.
That is not a limitation. It is a design boundary.
A governance system that tries to encode all human discipline into the schema becomes brittle and unmaintainable. Some rules belong in machine-validated structure. Others belong in operator practice.
A simplified educational example makes the difference concrete.
The schema requires that invocation be declared:
The Playbook explains how to use it correctly:
- Use README-as-Protocol as the default starting mode.
- Do not submit a partially completed archive to the validator as if it were final.
- Treat invariant track assignment as the single source of truth.
- Validate in this order: schema, invocation completeness, self-test coverage, provenance completeness, then track consistency.
The schema can require that invocation exists.
It cannot require that the operator uses it well.
README-as-Protocol works for the widest range of projects without requiring anything beyond a text file. That makes it the recommended default. But it is not the only option. More installed or infrastructure-heavy approaches may be better in some environments. The Playbook documents when the default is no longer enough — and what to do next.
7. The Distance from v0.0.1 to an Operative Schema
Part 2 named three failures in v0.0.1.
Failure 1: Scoring with no defined semantics.
The earliest version used hardcoded values with no clear combination rule or enforced model.
→ Closed in v0.1.0 (implementable formula) and v0.1.7 (structured scoring plus fail-closed admission).
Failure 2: Invariants encoded as comments.
The earliest version used plain strings where governance objects were needed.
→ Partially closed in v0.1.5. Fully closed in v0.1.8 when invariants became structured, referenceable, severity-bearing entries.
Failure 3: No path to the model.
The archive existed, but the model had no reliable way to know it existed.
→ Closed in v0.1.8 when invocation became a declared protocol and session start required proof of archive load.
That progression can be summarized simply:
The schema existed. Then governance moved into the schema. Then the schema reached the model. Only then did governance become operative.
That is the real distance from v0.0.1 to this point.
8. Where This Leaves MICA
At this stage, MICA is no longer just a memory format.
It is no longer just a structured archive.
It is a runtime governance contract:
- what context is allowed in
- what must remain true
- how the archive is loaded
- how drift is handled
- how readiness is reported before work begins
That is a different category of system.
9. What Comes Next
The next part of this series steps back from version history and asks a broader question:
Where does MICA sit in the context engineering landscape that already existed around it?
The answer is narrower than most people expect, and more specific than most framings allow.
Named decision from this post: An AI session already uses the README as an orientation surface. Formalizing that behavior as a schema-level invocation protocol is not a trick. It is the recognition that the mechanism already existed — and needed to be declared, not invented.
MICA is part of the Flamehaven governance-first AI systems practice. Schema, technical report, and production instance: flamehaven.space. Open-source tooling: AI-SLOP-Detector. All schema references follow the v0.1.8.1 Universal standard unless a specific earlier version is named.
Share
Continue the series
View all in seriesPrevious in MICA Series
The Stake Was Governance Outside the Schema. MICA v0.1.5 Pulled It In
Series continuation
This is currently the latest published entry.