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.
🔸 Invocation Hierarchy: The operational ladder — natural, guided, forced — that determines how MICA actually reaches a live session.
🔸 Activation Packet: The compiled session-start object that declares read targets, load state, self-test posture, drift status, and gate outcome.
🔸 Session Report: The structured opening output that declares what was loaded, what the self-test found, and whether the session gate is open.
🔸 README-as-Protocol: The pattern where the model's natural tendency to read the README first is formalized as a declared invocation mechanism. Introduced in v0.1.8.
1. Where Part 6 Left Off
Part 6 showed what MICA looks like inside a single maintenance agent — session report, drift detection, design invariants, deviation log. The structure held. The protocol ran.
Part 6 ended with a harder question: what happens when accumulated session knowledge needs to govern the next session — inside a tool that runs within AI workflows itself?
The answer depends on a prior question: does the next session actually load what was accumulated?
That is not a schema problem. It is an entrypoint problem.
2. The Gap README-as-Protocol Left Open
Part 4 made a specific assumption: in many repository-based AI workflows, the README is already the model's first orientation surface.
That observation became README-as-Protocol.
Instead of inventing a new installation mechanism, MICA formalized an existing behavior: the model reads the README, the README points to the archive, and the session is expected to load context, run checks, and report readiness before work begins.
That assumption was useful.
It gave MICA a path into the session without requiring plugins, services, or custom host infrastructure.
But a protocol is not an entrypoint.
The README can declare where the archive is, what invariants matter, what the session report must contain. None of that guarantees sequencing. A model can still skim the README, jump directly into code, or begin work before declaring its load state.
A gate without a consequence is still only etiquette.
That is the gap this version had to close.
3. The Answer: An Invocation Hierarchy
MICA does not auto-invoke by magic. If no human, host, wrapper, or launcher calls the memory contract, the archive can exist without governing anything. This is the same truth Part 2 identified: the structure can exist, and the model can still have no reliable way to know it exists.
The answer is an explicit hierarchy.
Natural — the model reads the project surface voluntarily: README, mica.yaml, archive JSON, playbook. No intervention required.
Guided — a host agent requests the activation packet before work begins. The packet declares read targets, self-test posture, drift state, and gate outcome. The host uses it to preflight the session.
Forced — a launcher blocks repository work until the session report clears. This is the strongest path and the least elegant one. It is also the one that survives noisy real-world terminal workflows.
4. What Changed in Code
Three concrete moves made this operational.
Session report became a real runtime output.
parser.add_argument(
"--format",
choices=["text", "json", "hook", "session-report"],
default="text"
)
The opening report is now a compiled object — not a protocol expectation, not a prose description. A host can consume it directly.
Invocation is now compiled, not described.
mica_invoke.py compiles read targets and session report into one activation packet:
packet = {
"mode": mode,
"entry_strategy": mode,
"read_targets": _layer_targets(project_root),
"session_report": report,
}
This is the shift from documentation-first startup to packet-first startup. The host no longer has to infer the sequence from prose.
In guided mode, the output is already shaped for host consumption:
{
"mode": "guided",
"entry_strategy": "guided",
"read_targets": [
{"name": "readme", "...": "..."},
{"name": "mica_yaml", "...": "..."},
{"name": "archive", "...": "..."},
{"name": "playbook", "...": "..."},
{"name": "lessons", "...": "..."}
],
"session_report": {
"archive_version": "1.7.8",
"self_test": {"pct": "CLOSED", "closed_contract": true},
"drift_status": {"status": "NO_DRIFT"},
"gate": "PASS"
},
"directive": "Host agent should load declared MICA surfaces first and use the session report as opening state."
}
Forced mode now has consequence.
if args.mode == "forced" and packet["session_report"].get("gate") == "BLOCKED":
sys.exit(1)
The simplest entry surface:
@echo off
python "%~dp0tools\mica_invoke.py" %*
That wrapper gives MICA an enforceable terminal entrypoint instead of relying on good behavior.
5. STEM-BIO-AI: The Cleaner Case
STEM-BIO-AI already had a mature MICA memory layer — archive, playbook, lessons, invocation protocol, drift profile. What changed was not the memory model. It was how that model becomes operative before work begins.
That difference is visible across all three invocation modes.
In natural mode, the helper preserves the README-first path and makes the expected read order explicit:
[MICA INVOKE] mode=natural
Gate : PASS
State : INVOCATION_MODE
PCT : CLOSED
...
Directive: Prefer reading README first, then load mica.yaml, archive, and playbook before scan work.
In guided mode, the same startup becomes a host-consumable packet:
{
"mode": "guided",
"read_targets": ["readme", "mica_yaml", "archive", "playbook", "lessons"],
"session_report": {
"archive_version": "1.7.8",
"self_test": {"pct": "CLOSED", "closed_contract": true},
"drift_status": {"status": "NO_DRIFT"},
"gate": "PASS"
}
}
In forced mode, the launcher uses the same contract as a gate:
[MICA INVOKE] mode=forced
Gate : PASS
State : INVOCATION_MODE
PCT : CLOSED
...
Directive: Block work until the session report gate is not BLOCKED.
The session report now looks like this:
[SESSION READY]
Archive: 1.7.8
Load: {"state": "INVOCATION_MODE", "mica_yaml": "memory\\mica.yaml"}
Self-test: {"pct": "CLOSED", "closed_contract": true}
Drift: {"status": "NO_DRIFT"}
Active invariants: {"critical_count": 15, "high_count": 3}
Gate: PASS
Before, the package told the operator how to start correctly. Now, the session declares whether it actually did.
Before this version, starting a STEM-BIO-AI session correctly still depended on the operator remembering to load the right memory surfaces in the right order. Now that dependency can move upward: in guided mode to the host, and in forced mode to the launcher.
6. CCGE: The Harder Case
CCGE is more important precisely because it is harder. It is already a governance-heavy runtime. If MICA's identity were weak, it would disappear into the larger framework.
CCGE here is the Care Chain Governance Engine: a fail-closed clinical governance runtime with its own execution core, artifact generation, policy layers, and approval logic. That is why it is the harder case. MICA is not being tested in isolation. It is being tested inside a system dense enough to swallow it.
It did not.
The boundary stayed explicit:
- MICA = invocation, memory, invariants, drift control
- CCGE Core = fail-closed runtime and artifact generation
- STEM-AI = trust re-audit and classification
That is the important architectural result. In STEM-BIO-AI, MICA is already close to the center of the tool's operational identity. In CCGE, MICA has to retain its own identity inside a much larger runtime. It does so by remaining responsible for invocation, memory, invariants, and drift control, while CCGE Core remains responsible for fail-closed execution and artifact logic.
The current session report in CCGE:
[SESSION READY]
Archive: None
Load: {"state": "INVOCATION_MODE", "mica_yaml": "mica.yaml"}
Self-test: {"pct": "CLOSED", "closed_contract": true}
Drift: {"status": "NO_DRIFT"}
Active invariants: {"critical_count": 0, "high_count": 0}
Gate: PASS
Archive: None with Gate: PASS is not a contradiction. The baseline archive does not yet expose a project.version field. MICA detected that gap and reported it before any work began. A system that hides its own incompleteness is not governed. A system that surfaces it at session start is.
The reason is concrete: the active archive is still a baseline integration memory object, not yet a fully target-bound archive. Its project block still carries placeholders like:
"project": {
"name": "<target-repo-name>",
"path": "<absolute-or-repo-relative-path>",
"owner": "<org-or-maintainer>",
"integration_program": "CCGE Unified Model",
"target_status": "phase_1_candidate"
}
So the current report is telling the truth about what exists: a coherent MICA package around a still-baseline archive.
A README might have let that gap stay invisible. The session report surfaced it immediately. That is what honest governance looks like before an archive is fully populated.
7. What This Means for Anyone Building Agent Workflows
Three lessons from running this against two different projects.
Human-readable startup is not enough. If the only valid path lives in a README, the protocol is vulnerable to partial reading and host variance. STEM-BIO-AI is the clean example here: the memory layer was already mature, but correct startup still depended too much on the operator remembering to load it.
Session-start state must be machine-usable. If a host agent cannot consume the startup declaration as a structured object, it cannot reliably preflight the session. That is why guided mode matters more than another explanatory document: it gives the host an object to act on, not just instructions to interpret.
A gate needs an entrypoint. A session report can be a conceptual hard gate, but until a launcher or host uses it as an entry condition, it remains a convention. CCGE is the stronger proof of that point because the environment is already dense with governance logic; without an explicit entry surface, MICA would have been easy to blur into the surrounding framework instead of remaining its own startup layer.
8. What This Does Not Claim
MICA does not self-invoke automatically in all environments. There is still no natural law that forces an LLM session to load the governed archive first.
The real claim is narrower:
- MICA can now be read naturally
- MICA can now be requested deliberately
- MICA can now be enforced mechanically
Not total automation. A realistic path to enforceable startup.
9. What Part 8 Will Address
The startup path is now much stronger.
But one question remains:
How much of the session-start contract should be owned by the archive itself, and how much should remain a runtime default?
The current line can emit session-report, compile guided packets, and block in forced mode. The next step is stricter archive ownership — richer session_report_format, explicit per-archive session_gate_policy, better drift contracts.
Part 8 is not about whether MICA should govern startup. It already does. It is about how much of that behavior should be declared by the archive rather than inferred by the runtime.
The series continues only where there is something concrete to specify, test, or correct.
Named decision from this post: A protocol is not yet an entrypoint. MICA becomes operational only when invocation is structured as natural, guided, or forced — and the session begins from a declared activation packet, not from hope.
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.
