The 4-Map and the Harnesses Behind It

The 4-Map is the loop I keep running on outside input. Audit it. Diagram it. Build it. Deliver it. The loop has run on enough inputs now that I want to write down what each phase actually does, name the existing PAI harness behind each one, and surface the rule that makes the whole thing survive past the first run.

PAI runs problem-solving at three abstraction levels. The 4-Map is the middle one. Here is the layout I keep in my head:

Level	Name	Role
0 — META	Algorithm (PAI meta-harness)	Always runs whole for any complex task; seven phases (OBSERVE → THINK → PLAN → BUILD → EXECUTE → VERIFY → LEARN); never invoked in parts
1 — PROCESS	4-Map (AUDIT → DIAGRAM → BUILD → DELIVER)	Production process for shipping lasting artifacts; lives inside the Algorithm when the task is production-shaped
2 — OUTPUT SHAPE	Harness · Atom · Pattern · Doctrine · Essay · Code	The actual deliverable; shape follows work

The previous post in this series covered Level 2 — the four-property scope-gate that decides whether work earns harness shape at all. This post sits one zoom-out: the production loop around harness work, and the rule that keeps it honest across runs.

The loop’s universal claim is empirical, not proven. The composition rule below is what makes it testable.

The shape of the loop

The 4-Map is a four-phase cycle applied to outside input. Each phase produces one named artifact. Each phase has a deterministic validation gate. The next phase depends on the previous artifact passing its gate.

The 4-Map opportunity harness: four outer phases AUDIT, DIAGRAM, BUILD, DELIVER, with inner-harness slots per phase. — The 4-Map at the level I keep in my head: four phases, inner-harness slots per phase. Implementation has more nodes than this; the mental model does not.

Each phase’s Action is itself a fixed-plan harness. The 4-Map is a harness-of-harnesses; the composition shape is linear (the artifact of phase N is the input of phase N+1).

The high-level mapping from phase to existing PAI harness:

Phase     │ First-principles work               │ Existing PAI harness
──────────┼─────────────────────────────────────┼────────────────────────────────
AUDIT     │ discovery + 5-axis 90X scoring      │ work-audit  (internal source)
          │                                     │ outside-source-audit (external)
DIAGRAM   │ decomposition + substrate-mapping   │ FOLD: fixed-plan-harness-template
          │                                     │       (workflow case)
          │                                     │ FOLD: kn-to-action blueprint mode
          │                                     │       (knowledge case)
BUILD     │ composition + canonical-shape impl. │ The harness fleet (the BUILD outputs)
          │                                     │ + harness-creator (compose / check / scaffold)
          │                                     │ + the composition discipline gate
DELIVER   │ handoff + post-launch checkpoint    │ FOLD: PAI-infra path
          │                                     │       (session-wrapup + dashboard + kn)
          │                                     │ FOLD: Portfolio path
          │                                     │       (session-wrapup + narrativ-refactor +
          │                                     │        project-library + (optional) blog)
          │                                     │ External-client variant: not yet built

What follows walks each row.

AUDIT

AUDIT is the phase where I figure out what is actually worth automating. It is discovery and scoring, applied to the scope I care about right now.

The mechanical work: walk a defined scope (a person’s workflows for a window, one team’s tickets, one repo’s PRs, one community template), log every repeated activity, score each on five axes — Volume, Time-per-instance, Structurability, Cost-of-error, Emotional-tax — on a 1-10 scale. Sum to a 90X score. Surface the top candidates. The threshold for “this is worth automating” is Σ ≥ 29 with Structurability ≥ 7/10.

The validation gate that AUDIT must pass before DIAGRAM gets its input:

≥10 distinct activities logged with real time measurements (not estimates)
Every activity has all five 90X scores filled
Top-3 candidates have Structurability ≥ 7/10
Hours-reclaimable estimate per candidate is derived from the audit log, never a round number

Output: an audit document with the activity log, the per-activity scores, the top-3 ranked, and the reclaimable-hours estimate per candidate.

The PAI harness behind this phase: work-audit. Two flavors:

work-audit for internal sources — scans command history, closed work items per repo, knowledge-archive entry counts, shell history, file mtimes across project directories. Produces the activity log mechanically.
outside-source-audit for external sources — ingests outside content (a tutorial, a community template, an article) via the url-to-kn ingestion atom, then scores 90X against the same axes.

What stays human is the synthesis prose at the top of the audit doc — “top candidates after cross-project re-ranking,” “what to file as a build candidate this cycle.” The runner produces data. I decide. AUDIT mirrors kn-to-action’s split: machine scores, human picks.

DIAGRAM

DIAGRAM is where I commit to a shape. The audit handed me a top candidate; this phase decides what we are actually building and on what substrate.

The mechanical work: take the audit’s top candidate, extract the current process as a flow (triggers, decisions, artifacts), label every step as one of four kinds (human-only, deterministic, LLM-suitable, needs-data-access), produce a target-state Mermaid diagram, write the component inventory mapped to substrate I actually have. Name the minimum viable automation slice — the smallest subset that ships independently and produces measurable value.

Validation gate:

The Mermaid diagram renders without parse errors
Every step labelled with one of the four categories
At least one decision point flagged human-in-the-loop
Component list maps to tools the operator actually has access to (no mythical APIs)
The minimum-viable slice ships alone

Output: a blueprint document, the Mermaid source, and a component inventory with auth and rate-limit notes per component.

The PAI harness behind this phase: FOLD. There is no separate blueprint-harness runner because two existing artifacts already serve as the diagram format for two input shapes:

Workflow case: the canonical fixed-plan-harness-template is the workflow blueprint format. The 4-section block per phase (Input requirements / Action / Validation gate / Output artifact) IS the diagram of the workflow being built. Every shipped harness in the fleet was authored against this template directly.
Knowledge case: kn-to-action blueprint mode produces 7-section bundle blueprints — COMPONENTS, DEPENDENCIES, FILE_STRUCTURE, INTERFACES, MESSAGE_FLOW, INSTALL_ORDER, CONFIG_SURFACE. This is the blueprint format for third-party content (a tutorial, an architecture doc, a framework’s source).

The FOLD means the DIAGRAM phase has no runner of its own. The templates are the diagram. That works for workflow and knowledge inputs. If a future input fits neither shape, this phase needs a third FOLD or a real blueprint-harness.

BUILD

BUILD is where the discipline lives. It is composition and canonical-shape implementation — and the rule that makes the output more than a one-off script.

The mechanical work: take the blueprint, decompose into atoms (smallest reusable transformations, each with a single typed input and a single typed output), classify each atom Reuse / Reshape / Rebuild, ship new atoms in canonical harness shape, package the composition itself as a harness rather than as inline script.

The composition rule has three orderings:

For each atom the BUILD phase needs:

    ┌─ existing PAI harness or skill fits?      ──→ REUSE
    │                                                (cite the existing path; do not fork)
    │
    ├─ small extension makes an existing atom    ──→ RESHAPE
    │  fit?                                          (file an issue against the existing atom;
    │                                                 do not fork)
    │
    └─ nothing existing fits, AND the new atom   ──→ REBUILD
       plausibly recurs in future workflows           (canonical harness shape: spec + runner +
                                                       state directory + flags + cost log)

Validation gate at BUILD exit (the composition discipline, mandatory):

The decomposition is named (≥3 atoms classified Reuse / Reshape / Rebuild)
Every Rebuild atom has a spec file matching the canonical harness template
Every Reuse atom cites the existing harness or skill path
The composition is documented as a harness, not as a one-off script
No inline implementation in the composition runner could plausibly serve a different future workflow

Plus: the minimum-viable slice runs end-to-end on real inputs from Phase 1’s log. Per-run cost and time are measured. Failure modes are enumerated with handlers (retry, escalate, abort). The reclaimable-hours measurement reproduces Phase-1’s estimate within ±25%.

Output: a running system (binary, workflow, or service), a runbook, the measured reclaim number versus Phase-1’s prediction, and any new atoms living in the canonical harness shape.

The PAI harness behind this phase is two things together — there is no single build-harness runner, and that is by design.

The fleet of canonical-shape harnesses that are the BUILD outputs from prior runs. A representative sampling, named by handle:

url-to-kn — URL ingestion to a knowledge-archive entry (a foundational atom)
kn-to-action — knowledge entry to actionable artifact, with blueprint mode and others
web-search — grounded web search
competitor-research — composition harness on top of web-search + url-to-kn + kn-to-action
outside-source-audit — the Phase-1 external-source variant
narrativ-refactor — portfolio narrative cascade
session-wrapup — session close, commit, push, knowledge entry, dashboard update
work-audit — the Phase-1 internal-source variant named above
harness-creator — the meta-tool

All of these source the shared harness runtime. All have --resume and --force flags. All log per-run cost and time to a state directory.

harness-creator is the meta-tool that scaffolds, composes, and checks new harnesses. Three modes:

compose — when the needed atoms already exist, wire them together as a new composition harness rather than reinventing
check — run conformance fitness functions across a harness or the fleet
scaffold — when a missing atom is real, draft a new harness in canonical shape

Refusal is part of the product. harness-creator refuses non-workflow-shaped requests. If the asked-for output is a one-off essay, doctrine doc, or debugging session, the tool does not generate harness boilerplate — it returns “this is not workflow-shaped, use a different Level 2 output.”

DELIVER

DELIVER is handoff. The work is built and verified; what is left is putting it in the consumer’s hands in a form they will actually use.

The mechanical work: convert the audit, the blueprint, and the measured value into a format the consumer (future-self, internal team, or external client) actually reads. Transfer access and ownership. Document the rollback procedure. Schedule the post-launch review.

Validation gate:

The deliverable reflects the Phase-3-measured reclaim, not the Phase-1 prediction
The handoff artifact is self-contained — a new operator can run with just this
A rollback or pause procedure is documented
At least one post-launch review is scheduled

Output: a deliverable package and a post-launch checkpoint in the system of record.

The PAI harness behind this phase: FOLD composition, with two paths for two consumers:

Path	Components	Consumer
PAI-infra delivery	`session-wrapup` + dashboard update + knowledge entry + (sometimes) ADR	future-self
Portfolio delivery	`session-wrapup` + `narrativ-refactor` + project-library entry + (optional) blog post	external readers

There is also a notional external-client delivery path — deck, runbook, demo link, pricing anchored to measured-hours-reclaimed × blended hourly. That path is not yet built.

There is no single delivery-harness runner. DELIVER is a composition of existing harnesses and event-driven hooks, glued by session timing.

The composition discipline that makes the loop survive past the first run

The 4-Map makes a large claim: any outside input — a community template, a competitor’s product, a paper, a customer process — can pass through this loop and come out as a piece of the operating system you actually run on.

I had to learn the hard way that the claim only holds when one rule is attached. Without it, every run produces a one-shot script. The fleet stays the size it was. The next run starts from scratch. The universal claim degrades to we can build anything if we rewrite everything every time, which is not a claim worth defending.

The rule is in the project’s ADR ledger: the BUILD phase MUST produce composable atoms in canonical harness shapes. The 5-checkbox gate above is how the rule fires. Miss any box, BUILD does not exit.

The cost is real. A 4-Map run that produces atoms takes longer than a one-shot script would have — there is decomposition, spec writing, and gate checking on top of the workflow itself. With the rule applied, every run produces atoms a future run can reach for. The next run either reuses an atom (the fleet was right), reshapes one (the fleet was almost right), or produces a new one (genuine novelty). Over enough runs, that is what makes the loop a loop and not a treadmill.

The rule is the test surface. If a future run produces an atom and the next run cannot reuse it, either the rule was applied wrong or the rule is wrong-shaped. The post-mortem is short either way; the next ADR follows.

Open questions and unfinished work

A short list of what I do not yet know about this loop:

AUDIT/BUILD decoupling. BUILD fires conditionally on AUDIT producing a candidate; DELIVER unconditionally captures the audit. This was a clarification that emerged from running the loop, not a property of the original spec.
External-client DELIVER path. Notional and unimplemented. The dual-path FOLD above covers internal consumers only.
Non-workflow input. Untested. AUDIT assumes activities decompose into discrete steps with stable scoring axes; discovery work does not, creative work scores poorly on Structurability by definition, and investigative work has Cost-of-error scores impossible to bound. The current hypothesis: for non-workflow input, AUDIT returns “this is not workflow-shaped” as an honest output and the loop refuses BUILD, routing the work to a different primitive (research harness, creative workbench, investigation notebook). Untested.
BUILD orchestrator. There is no runner orchestrating the BUILD phase as a whole. The current implementation: the fleet, the composition rule, the 5-checkbox gate, and harness-creator for atom-level scaffolding. Whether a full BUILD-orchestrator harness should exist is an open question.

Where this post sits

Three pieces compose into the system I actually run on: the harness scope-gate from the previous post (does this work earn harness shape?), the 4-Map walked here (how does outside input become a candidate for that shape?), and the composition rule (does the harness I build today survive into the next session?). Each one is a binary gate; together they keep the system from sprawling.

The next post in the series will cover input that is not workflow-shaped — where this loop’s reach is least certain and the rule has the most to learn.