Back to buildsBUILD RECORD

Research Workflow Engine / Sourcing workspace / 2026

Continuing research from a saved checkpoint.

Immutable revisions preserve the work already captured while letting an active research run continue across sessions and recover from access pauses.

Confidential work. Names and identifying business details have been changed.

ROLE
Software engineering
STATE OF THE BUILD
In progress
RECORD UPDATED

THE WORK

The project.

Research Workflow Engine keeps a research run usable beyond one browser session. It records observations as immutable SQLite revisions, checks exactly what a new or resumed session may change, and derives assessments without replacing the collected material. Its Research MCP Service supplies the tool interface, while versioned exports give Operations Snapshot Dashboard a separate read-only view.

ATTEMPTS & CORRECTIONS

What changed along the way.

  1. Recovering research when the original tab was gone
    At first
    Browser research paused for human verification, but continuing depended on finding the original tab after the handoff.
    What needed to change
    The operator completed the challenge, then the next browser session couldn't find that tab. The workflow treated the run as unrecoverable even though its exact research position was still saved.
    The change
    Recovery now starts from the saved checkpoint instead of the temporary tab handle. After explicit human confirmation, it can use a matching or fresh tab in the selected browser. The query, position, counts, limits and expiry must stay the same, and another access barrier stops recovery.
    The result
    The source now provides a way back to the recorded research position without restarting the run or storing browser-session data. Tests define valid tab replacement and reject changed checkpoints and expired recovery. Those definitions were reviewed, not rerun for this account.
  2. Allowing fresh work after a completed session
    At first
    Each research source had a stable checkpoint. Finishing a browser session marked it completed, and the transition table allowed no further session from that state.
    What needed to change
    The wider research run could still need that source again. It remained active, but its checkpoint couldn't represent the next piece of work.
    The change
    Completion now closes the browser session rather than permanently closing the source. An active parent run can append the next session under the same checkpoint, with an incremented sequence and fresh fingerprints. Previous revisions stay closed, earlier completions can't count twice, and a finished parent run still rejects new work.
    The result
    Research can continue while keeping its completed sessions intact. Test definitions cover a valid next session and reject reused sequences and closed parent runs. They weren't rerun for this account.

IMPLEMENTATION

Design choices.

  1. One source keeps one checkpoint identity within a run. Appending revisions preserves earlier observations while allowing new sessions; continuing the research doesn't require reopening or duplicating completed work.
  2. Starting another session and recovering a paused one are different operations. New work needs the next sequence and fresh fingerprints. Recovery must return to the saved position, not quietly become a different query with a longer expiry.
  3. Recovery requires explicit human confirmation followed by a fresh observation of normal access. A replacement tab can carry the work on, but it can't bypass another access barrier or revive an expired pause.
  4. Assessments remain separate from missing information. The calculator can explain the records it has; it can't turn an uncollected observation into support for a decision.
  5. The core makes no network requests. It checks the consistency of supplied records and their transitions, while checking what a website actually shows remains with the browser workflow and operator.

HOW IT FITS TOGETHER

Architecture.

  • Browser work arrives as typed observations through Research MCP Service over STDIO. The service validates the request and resolves its run, selected source and expected previous revision. Browser credentials and sessions stay outside the core.
  • The parent's domain package decides whether the next checkpoint is a valid continuation. A new session advances its sequence; a recovery must preserve the paused query, position, counts, limits and expiry. Storage then appends the accepted revision and its audit record under the existing checkpoint identity.
  • Calculation packages use the saved observations to produce assessments without rewriting them. This keeps what was collected separate from what the software concludes, including gaps that a favourable score can't fill.
  • Research MCP Service has its own build record for protocol, validation and packaging details; checkpoint rules, calculations and storage remain in the parent packages. Operations Snapshot Dashboard connects through its own MCP client and reads versioned exports, not the research database. These connections are implemented in the reviewed source.
Explore the architecture map9 components · 10 connections

Browser research outside a network-closed core

Codex collects observations and passes them to the local core. The core checks and stores them, but doesn't browse or act on external systems.

Direct callAsync taskResponse / returnBlocked / denied
Orchestration
External sources
Local core

Scroll or drag the background to move. Use the zoom buttons to resize.Arrow keys move between components. Enter selects.

Choose a component to explore

Select a numbered component on the map or use the component menu. Its details and connections will appear here.

No component selected.

All connections (10)
  1. 01 · Codex → 03 · Source pagesbounded browser research · Async task
  2. 03 · Source pages → 01 · Codexobserved facts · Response / return
  3. 03 · Source pages → 04 · Access stopaccess unavailable · Blocked / denied
  4. 04 · Access stop → 02 · Human access checkpointpause for confirmation · Response / return
  5. 02 · Human access checkpoint → 01 · Codexconfirm a bounded resume · Async task
  6. 01 · Codex → 05 · STDIO MCP contractstyped evidence · Direct call
  7. 05 · STDIO MCP contracts → 06 · Domain rulesvalidate domain scope · Direct call
  8. 06 · Domain rules → 07 · SQLite revisionsaccepted revision · Direct call
  9. 07 · SQLite revisions → 08 · Deterministic calculationsevidence and policy state · Response / return
  10. 08 · Deterministic calculations → 09 · Scoped decision reportsderived result · Direct call

MADE WITH

TypeScript · Node.js · MCP · Zod · SQLite · Drizzle · decimal.js

CHECKS & RESULTS

What was checked.

A source review shows what the code does. It is not a fresh test of the running app.

  1. Code and development records reviewedReviewed

    The code, tests and available development records were checked. Reported test results keep their original scope. No fresh app or live deployment check was run for this write-up.

    Scope of this check
    Code review, not a fresh run of the app

NEXT

Still to work through.

The state model makes research history recoverable and continued work explicit. It doesn't establish whether a supplied browser observation is true. This account includes uncommitted source and inspected test definitions, not a fresh test run or verification of the installed plugin.

FROM THE SAME WORK

Technical note

Letting a research run outlast its browser sessions