# Teaching Script — DD-13: OpenHarness (Academic Baseline) **Instructor notes**: ~2000 words. 11 slide cues. Pace: ~3 minutes per slide. The load-bearing idea is the objective-function distinction (inspectability under reproducibility vs capability under constraints) and the four-part compaction mechanism that makes it concrete. Watch for the score-interpretation slide — students will want to argue the score. Let them, then land the interpretation: the score reflects what OpenHarness is not, not what it is. --- [SLIDE 1 — Title] This is OpenHarness, the academic harness from the HKUDS lab, published April 2026. I want to start with the framing because it is the entire lecture: OpenHarness is not a production harness. It is not trying to be a production harness. If you finish this lecture thinking "30 out of 60, that is a weak harness," you have missed the point. The score reflects what OpenHarness is not — production-ready — not a failure of what it is — the cleanest mechanism reference in the roster. Module 3 points at this harness when it teaches compaction. That is why we are here. [SLIDE 2 — The thesis: inspectability, not capability] Here is the objective-function distinction that organizes everything. A production harness optimizes for capability under constraints — cost, latency, safety. It emits rich telemetry about a black box. Compaction is a recovery behavior, something the harness does because it has to when the context window fills. OpenHarness optimizes for a different objective function: inspectability under reproducibility. The question it answers is not "can I ship this?" but "can a paper make a defensible claim against this harness?" The diagnostic test is precise: can a researcher point at the exact mechanism that produced this decision, vary it, and measure the effect? If the answer is ever "it is buried in the framework," the harness has failed its purpose. So OpenHarness makes the box itself open, not just the telemetry about it. "Academic" here does not mean weak. It means a different goal. Both goals are legitimate; they are different goals. Hold that distinction and the rest of the lecture follows. [SLIDE 3 — Three properties that define academic] Three properties define the academic posture, and each is a deliberate architectural choice rather than a missing feature. First, inspectability. Every component — loop, tools, context, memory — is modular and individually examinable. You can study the compaction mechanism without the tool layer, the memory model without the loop, the loop without the memory. Module 10 frames observability as a property of what you can see. OpenHarness treats it as a property of what you can isolate. Related but distinct. Second, auto-compaction visibility. The compaction mechanism is a first-class, named, parameterized component — not an emergent behavior of the loop. You can see when it triggers, what it summarizes, what it discards, what it preserves. In a production harness, compaction is usually entangled with the session store, the provider's token accounting, and the framework's retry logic. OpenHarness pulls it out as a named thing. Third, transparent decisions. Every harness decision — tool selection, stop condition, context pruning — is logged at the point it is made, with the inputs that produced it. Not as an after-the-fact trace reconstruction, but as a first-class record. The distinction that matters: "we can reproduce the run" is weaker than "we can defend why the run went the way it did." OpenHarness delivers the latter. [SLIDE 4 — Architecture: swappable modular components] The architecture reflects those properties. Each Module 0.1 job — loop, tools, safety, context, memory — is a separate, swappable component with a documented interface. The Loop is a thin orchestrator: it calls the model, dispatches tools, observes stop conditions. The other four are the data planes the Loop reads from and writes to. The Tool Registry is small and stable — research-minimal. This is the opposite of a production harness's incentive, where more tools means more capability means better benchmarks. For research, a large tool set is noise: it confounds the question "what did the model do?" with "what did the tools enable?" OpenHarness keeps the surface small so the model's decisions are the signal. And there is ohmo — the built-in personal agent. ohmo exercises every component so a researcher can run it, vary a parameter — compaction threshold, memory tier, tool set — and measure the effect on a benchmark without rebuilding the harness. ohmo is to OpenHarness what Pi is to the minimal-harness category: the readable instance that proves the architecture. [SLIDE 5 — The auto-compaction four-part mechanism] This is the headline contribution and the reason Module 3 cites this harness. Compaction in most production harnesses is a recovery behavior — something the harness does because it has to. In OpenHarness, compaction is a designed mechanism with four visible parts. Part one: a trigger predicate. A declared condition — token threshold, message count, or a custom predicate — that decides when compaction fires. A function you can read. Not magic, not buried. Part two: a selection policy. Which messages and tool results get summarized, which get preserved verbatim, which get dropped. The policy is named and parameterized, not implicit. Part three: a summarization step. The actual summarization call, model-based, with its own logged inputs and outputs. You can audit what the summarizer was shown and what it produced. Part four — the load-bearing detail — a non-destructive record. The original context is retained for analysis even after the compacted version is what the model sees on the next turn. The on-disk truth is never rewritten, only the in-context view is swapped. Because all four parts are individually examinable, a researcher can ask questions a production harness cannot answer without instrumentation. Did compaction change the outcome? Would a different selection policy have preserved the critical instruction? Is the summarizer introducing drift? Module 3 points here precisely because the mechanism is studiable rather than merely present. And notice — this mirrors DD-21 Tau's `CompactionEntry` with `replaces_entry_ids`. Both harnesses refuse to overwrite the on-disk truth. That is not a coincidence; it is the event-sourcing principle from Module 8 showing up as a shared design. [SLIDE 6 — Explicit tiered memory] The memory model. OpenHarness treats memory as an explicit, tiered abstraction rather than an emergent property of the context window. Three tiers, mapped onto Module 4's vocabulary. Working memory: the current context window, post-compaction. Episodic memory: prior turns and sessions, retrievable but not in-context by default. Semantic memory: distilled facts the agent has learned, keyed for retrieval. The architectural choice that distinguishes OpenHarness from production harnesses: these tiers are separate stores with declared interfaces, not layers of the same buffer. This makes the read path and the write path individually auditable — the property Module 4.3 wants when it talks about write-gating. The cost is integration friction. A production harness conflates these tiers precisely because doing so is faster and cheaper. OpenHarness pays the friction to buy the inspectability. [SLIDE 7 — Score: 30/60, the interpretation slide] Now the score slide, and I want you to sit with this because it is where most students get confused. OpenHarness scores 30 out of 60. The rubric scores production-readiness across all eleven modules. On Module 3, Context, it scores 4 out of 5 — the auto-compaction design is research-grade and inspectable, the reference implementation. On Module 4, Memory, it scores 4 out of 5 — explicit tiered stores with clean separation. On Module 10, Observability, it scores 4 out of 5 — inspectability is the product. But then look at the bottom. Module 5, Sandbox: 1 out of 5 — minimal, not the research question. Module 6, Permission: 2 out of 5 — below floor. Module 9, Verification: 1 out of 5 — none. Module 11, Security: 1 out of 5 — not the research question. Here is the interpretation that matters. As with DD-01 Pi, the absolute score is low because the rubric measures production-readiness across all dimensions. OpenHarness is not trying to be production-grade across all dimensions. It is deliberately inspectable. The score reflects what OpenHarness is not — production-ready — not a failure of what it is — the cleanest mechanism reference in the roster. Its value is pedagogical and methodological: it is the harness that makes every other harness's claims falsifiable. You cannot falsify a claim against a black box. You can falsify a claim against OpenHarness. [SLIDE 8 — The OpenHarness-vs-Tau inspectability axis] The closest peer in the roster on inspectability is Tau, DD-21. Both are inspectability-first, but they inspect different things. OpenHarness makes what the harness did visible — decisions logged at source with inputs. Tau makes what the harness is visible — code structure, session tree, machine-readable event union. OpenHarness optimizes for legibility-of-behavior. Tau optimizes for legibility-of-code. The shared design between them is the non-destructive record. Both refuse to overwrite the on-disk truth. OpenHarness retains the original context. Tau retains the replacement entry chain. This is the event-sourcing principle from Module 8 showing up as a convergent design. And here is the gap OpenHarness would need to close to hit a 5 on Module 10. OpenHarness's logs are human-readable. Tau's event union is machine-readable. The DD-14 Mastra standard is machine-readable structured events. So OpenHarness approaches the DD-14 standard but does not meet it. That gap — emit machine-readable decision logs — is the third thing to fix if you misuse this as production. [SLIDE 9 — MLSecOps relevance: the lab target] For MLSecOps, OpenHarness is a lab target, not a deployment target. Its inspectability is its security value: every component can be audited in isolation, making it the best harness for studying how a specific mechanism works without production noise obscuring the signal. Two questions you can only answer against OpenHarness. First: compaction-induced drift. Does the summarizer drop a security-critical instruction when it compacts? Only OpenHarness logs the summarization step with its inputs and outputs, so only against OpenHarness can you audit what the summarizer saw and what it produced. Second: memory-tier poisoning. Can a write to semantic memory survive compaction? Only OpenHarness has separate tiered stores with declared interfaces, so only against OpenHarness can you trace a write across tiers without production conflation blurring the path. But the caveat: inspectability is a research property, not a security property. A visible compaction mechanism is not a safe compaction mechanism. Read inspectability as "I can see what happens," not "what happens is safe." For secured mechanisms, use a harness with the security modules implemented. [SLIDE 10 — Three better, three to fix] Three things OpenHarness does better. Compaction as a designed mechanism — the four-part design is the reference Module 3 teaches against. Inspectability-as-product — every decision logged at source with inputs. Non-destructive context record — original survives compaction, mirrors DD-21's design and Module 8's event-sourcing. Three things to fix if you misuse it as production. Add a sandbox — bash and exec run without containment; correct for research, fatal if shipped. Add a permission model — below floor; fine in the lab, not elsewhere. Emit machine-readable decision logs — the inspectability is currently human-readable; a structured schema would make it analyzable at scale and bring Module 10 observability up to the DD-21 and DD-14 event standard. The verdict: build on it for research and for studying mechanisms in isolation; do not ship it. Its role in the roster is methodological — the academic baseline that gives every production harness a defensible comparison reference. [SLIDE 11 — Takeaways] Five takeaways. One: OpenHarness optimizes for inspectability under reproducibility, not capability under constraints. A different objective function, not a weaker harness. Two: auto-compaction is a designed four-part mechanism — trigger, selection, summarization, non-destructive record. The Module 3 reference because the mechanism is studiable, not merely present. Three: the non-destructive record is the load-bearing detail. Original context survives compaction. Lets a researcher ask "did compaction change the outcome?" Four: the 30 out of 60 score reflects not-production, not design failure. Same pattern as DD-01 Pi. Its value is pedagogical and methodological. Five: the OpenHarness-versus-Tau axis is legibility-of-behavior versus legibility-of-code. Both inspectability-first, optimizing for complementary properties. The shared design is the non-destructive record. Next lecture is DD-14, Mastra — the machine-readable observability standard OpenHarness approaches but does not meet. The contrast will be instructive: Mastra is production observability with structured events. OpenHarness is research inspectability with human-readable logs. Same goal — see what the harness did — different objective function. --- **End of teaching script.** Lab: see `07-lab-spec.md` — implement OpenHarness's auto-compaction as a four-part mechanism in pure Python, verify the non-destructive property, test for compaction-induced drift.