doclayer
/ meta-harnesses / publish
scenario 05: publish
A
V
PUBLISH chain · DOC_PUBLISH/v1
  1. 01Bootstrap
  2. 02Plan
  3. 03Draft
  4. 04Review
  5. 05Publish
  6. 06Reader
architect: binding
single-author view · see scenario 07 for the multiplayer harness →
01Plan
02Draft
03Review
04Publish

Ship to a real domain

ready to publish
✓ both authors approved
✓ all 5 phase chains completed (DOC_PLAN, DOC_DRAFT, DOC_REVIEW)
✓ reader-harness manifest typechecked (12 atoms, 3 prior bindings)
✓ author voice models loaded (vishal: 412 lines · akhil: 287 lines)
generated · 1200×630 · regenerate
AI engineer PM / strategist researcher + ask reader
doclayer.live/rss.xml · auto-included
manifest preview · frozen · 4.2 KB
{ "phase": "publish", "meta": { "docId": "mh-1", "frozenAt": "2026-05-10T11:42Z" }, "root": [ { "kind": "reader-prior-picker", "presets": ["ai-engineer", "pm", "researcher"] }, { "kind": "evolving-explainer", "topic": "harness", "depth": 2, "bindings": { /* per-prior render */ } }, { "kind": "revision-variant", "variants": ["runtime", "chassis", "MDP"] }, { "kind": "comment-thread", "anchorBlockId": "root" } ] }
build · DOC_PUBLISH/v1
○compiling manifest…1.0s
○freezing reader-prior bindings…1.4s
○bundling reader-harness JS (12 KB)…1.6s
○deploying to doclayer.live…1.6s
○live✓
✓build complete5 steps · 6.3s
Co-author approval
Vishal · approved
ready to ship — looks clean
Akhil · approved
send it
Reader-harness preview · simulating
AI engineer PM researcher
⬢ doclayer.live/meta-harnesses-1-what-is-a-harness
live · just now ⎘doclayer.live/mh-1
← Architect re-binding for 'AI engineer' prior ← Architect re-binding for 'PM' prior ← Architect re-binding for 'researcher' prior

What is a harness?

The runtime around the model

A harness is the controller that wraps the transformer at inference time: the loop that decides which tokens to feed in, which tools to call, what to remember, and how to respond to outputs.

while (!done) { ctx = memory.recall(state) out = model.generate(ctx) state = harness.step(out) }

The transformer is policy. The harness is everything else. Scaling the policy doesn't fix harness shape — that's a different optimization problem entirely.

The shape of the AI product, not the model

If the model is the engine, the harness is the chassis. Two startups can use the same engine and ship completely different products — the chassis is what the user feels.

Think of harnesses like the difference between a sedan, a truck, and a sports car all running the same V8. The engine matters less than the form factor for what a customer is buying.

This is why scaling models doesn't dissolve startups. The harness — the product surface, the memory, the way the agent loops — is where the moat lives.

The decision process external to the policy

Define the harness H as the controller wrapping a parameterized policy πθ. H selects context, performs intermediate computation, and routes the policy's emissions back into state. The harness is, formally, an MDP whose action space includes invocations of πθ.

Scaling θ improves the policy's per-step behavior but does not constrain H's decision process — they are orthogonal optimization targets, and recent results (RLM hill-climbing) suggest the harness layer admits its own training signal.

preview live phase: publish chain: DOC_PUBLISH/v1 final · 3,580 words both authors approved cycling priors · simulation
← review all scenarios next: reader harness →
next: reader →