OpenHarness
Academic Baseline (HKUDS) · Deep-Dive DD-13 · Course 1
60 minutes · HKUDS lab, April 2026 · Research reproducibility, not production · Auto-compaction as designed four-part mechanism
The clean-room academic harness. Every component modular, every decision traceable, every mechanism examinable in isolation. Built so a paper can make a defensible claim against it. The harness Module 3 points at when it teaches compaction. 30/60 — the score reflects what it is not (production), not a failure of what it is (the cleanest mechanism reference in the roster).
Deep-Dives · The Harness Roster
The thesis — inspectability, not capability
PRODUCTION HARNESS
Optimizes capability under constraints (cost, latency, safety). Rich telemetry about a black box. Compaction is a recovery behavior.
OPENHARNESS
Optimizes inspectability under reproducibility. The box itself is open. Compaction is a designed mechanism with four visible parts.
THE DIAGNOSTIC QUESTION
"Can a researcher point at the mechanism that produced this decision, vary it, and measure the effect?" If the answer is buried in the framework, the harness has failed.
"Academic" is not weak. It optimizes for a different objective function. Production asks "can I ship this?" OpenHarness asks "can a paper make a defensible claim against this?" Both are legitimate; they are different goals.
Three properties that define "academic"
PROPERTY 1
Inspectability
Every component modular and individually examinable. Study compaction without the tool layer, memory without the loop. The box itself is open — not just the telemetry about it.
PROPERTY 2
Auto-compaction visibility
Compaction as a first-class, named, parameterized component. See when it triggers, what it summarizes, what it discards, what it preserves.
PROPERTY 3
Transparent decisions
Every decision (tool selection, stop condition, pruning) logged at source with inputs. First-class record, not after-the-fact trace reconstruction.
The distinction that matters: "we can reproduce the run" (trace reconstruction) is weaker than "we can defend why the run went the way it did" (decision-at-source logging). OpenHarness delivers the latter.
Architecture — swappable modular components
LOOP
The Loop
Calls model. Dispatches tools. Observes stop conditions. Thin orchestrator.
TOOLS
Tool Registry
Small, stable, research-minimal. Surface kept small so the model's decisions are the signal.
CONTEXT
Context Manager
Auto-compaction. Four-part mechanism. The Module 3 reference.
MEMORY
Memory
Explicit tiered stores: working, episodic, semantic. Separate stores, declared interfaces.
Plus a Decision Log — transparent, first-class. And ohmo, the built-in personal agent that exercises every component. ohmo is to OpenHarness what Pi (DD-01) is to the minimal-harness category: the readable instance that proves the architecture.
The auto-compaction four-part mechanism — Module 3 reference
PART 1
Trigger predicate
A declared condition (token threshold, message count, custom predicate). A function you can read — not magic, not buried.
PART 2
Selection policy
Which messages summarized, which preserved verbatim, which dropped. Named and parameterized, not implicit.
PART 3
Summarization step
Model-based. Its own logged inputs and outputs. Audit what the summarizer saw and what it produced.
PART 4
Non-destructive record
Original context retained for analysis. The on-disk truth never rewritten — only the in-context view swapped.
The load-bearing detail is Part 4. The non-destructive record lets a researcher ask "did compaction change the outcome?" — a question a production harness cannot answer without instrumentation. This is why Module 3 points here: the mechanism is studiable, not merely present.
Explicit tiered memory — separate stores, not layers
TIER 1
Working memory
The current context window, post-compaction. What the model sees right now.
TIER 2
Episodic memory
Prior turns, prior sessions. Retrievable but not in-context by default.
TIER 3
Semantic memory
Distilled facts the agent has learned, keyed for retrieval.
The architectural choice: separate stores with declared interfaces, not layers of the same buffer. This buys individually-auditable read path and write path — the property Module 4.3 (write-gating) wants. The cost is integration friction; production harnesses conflate the tiers because doing so is faster and cheaper.
Score: 30/60 — the score-interpretation slide
| Module | Score | Notes |
|---|
| M3 Context | 4/5 | Auto-compaction is research-grade and inspectable — the reference |
| M4 Memory | 4/5 | Explicit tiered stores; clean read/write separation |
| M10 Observability | 4/5 | Inspectability is the product; below 5 only because human-readable over machine-readable |
| M5 Sandbox | 1/5 | Minimal — not the research question |
| M6 Permission | 2/5 | Below floor; fine for research, fatal if shipped |
| M9 Verification | 1/5 | None |
| M11 Security | 1/5 | Not the research question |
The interpretation that matters. As with DD-01 (Pi), 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.
The OpenHarness-vs-Tau inspectability axis
OPENHARNESS — legibility-of-BEHAVIOR
Makes what the harness did visible. Decisions logged at source with inputs. Human-readable. Compaction mechanism examinable in isolation.
TAU (DD-21) — legibility-of-CODE
Makes what the harness is visible. Code structure, session tree, machine-readable event union. Compaction as CompactionEntry with replaces_entry_ids.
Shared design: the non-destructive record. Both refuse to overwrite the on-disk truth. OpenHarness retains the original context; Tau retains the replacement entry chain. The gap OpenHarness would need to close to meet the DD-14 (Mastra) observability standard: machine-readable logs, not human-readable.
MLSecOps relevance — the lab target
OpenHarness's 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.
Compaction-induced drift
Does the summarizer drop a security-critical instruction? Only answerable against a harness where the summarization step is logged with its inputs and outputs.
Memory-tier poisoning
Can a write to semantic memory survive compaction? Only answerable against a harness where the memory tiers are separate stores with declared interfaces.
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."
Three better, three to fix
THREE BETTER
- Compaction as a designed mechanism — the four-part trigger/select/summarize/record design is the reference Module 3 teaches against.
- Inspectability-as-product — every decision logged at source with inputs. Closest peer is DD-21's event union.
- Non-destructive context record — original survives compaction. Mirrors DD-21's
replaces_entry_ids and Module 8's event-sourcing.
THREE TO FIX (if misused as production)
- Add a sandbox — bash/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.
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, and the harness Module 3 points at when it teaches compaction.
Takeaways
- OpenHarness optimizes for inspectability under reproducibility — not capability under constraints. A different objective function, not a weaker harness.
- 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.
- The non-destructive record is the load-bearing detail — original context survives compaction. Lets a researcher ask "did compaction change the outcome?"
- The 30/60 score reflects not-production, not design failure — same pattern as DD-01 (Pi). Its value is pedagogical and methodological.
- The OpenHarness-vs-Tau axis is legibility-of-behavior vs legibility-of-code — both inspectability-first, optimizing for complementary properties. The shared design is the non-destructive record.
Next: DD-14 — Mastra (the machine-readable observability standard OpenHarness approaches but does not meet)