Skip to main content
TRW
LEDGER // WHY_TRW_EXISTS

Engineering context should survive the session.

TRW began with a practical problem: later AI-assisted sessions often had to rediscover requirements, decisions, and failure modes that a project had already encountered.

The framework preserves selected project context and delivery evidence so the next session has a better starting record—not a promise that every task automatically improves.

Context handoffPROJECT-LOCAL
  1. Working sessionDecisions and discoveries01
  2. Project recordSelected context and evidence02
  3. Later sessionRecall, re-check, continue03

ORIGIN // FROM_CONTEXT_LOSS

From notes to a durable work record

The product grew by separating what belongs to a conversation from what a project should retain.

  1. 01

    The session boundary

    Useful constraints and decisions lived in conversation history. Later sessions often had to rediscover them.

  2. 02

    The first durable artifacts

    Learning files and checkpoints made selected context available outside the conversation that produced it.

  3. 03

    A delivery contract

    Requirements, reported repository checks, exception state, and handoff notes became separate inspectable records.

  4. NOW

    An open, local-first framework

    TRW packages those mechanisms behind MCP tools that can be used across supported coding clients.

MECHANISM // NOT_MAGIC

Persistence creates a reviewable loop—not automatic improvement

A stored learning can help a later session avoid rediscovery. It can also become stale. The useful mechanism is capture, recall, re-verification, and retirement—not an unbounded compounding claim.

The reusable-knowledge pathVALIDATION REQUIRED
  1. 01

    Capture

    Record a material finding with project context.

  2. 02

    Preserve

    Keep it outside the conversation that produced it.

  3. 03

    Recall

    Surface eligible candidates for a later task.

  4. 04

    Re-check

    Validate the candidate against the current repository.

  5. 05

    Update

    Strengthen, supersede, or retire what changed.

NAME // THE_REAL_WORK

The name became a working principle

“The Real Work” emerged during early working sessions as shorthand for the part of engineering that generation alone does not solve: preserving the constraints, decisions, evidence, and hard-earned context that future work depends on.

The output is not only code. It is also the record that lets another person or agent understand what was attempted, checked, and left unresolved.

That is a product principle, not a claim of autonomous authorship or guaranteed compounding. TRW exists to make that record easier to create, inspect, and carry forward.

PRODUCT // WHAT_EXISTS

Four connected records, each with a boundary

TRW connects project memory, workflow state, handoff contracts, and reported delivery evidence. It does not replace your coding client, repository checks, or engineering judgment.

Project-local memory

Store material learnings and recall candidates in a later session.

BoundaryRecalled knowledge is context to re-check, not automatic truth.

Risk-scaled workflow

Choose a lighter or deeper ceremony based on the task and preserve recovery state.

BoundaryPhase guidance is advisory; the coding delivery gate is the hard boundary.

Portable handoffs

Make ownership, artifacts, dependencies, and next actions explicit.

BoundaryYour coding harness executes helpers; TRW supplies the coordination contract.

Requirements and evidence

Connect a requirement to implementation scope and caller-reported repository checks.

BoundaryTRW records check results; it does not independently execute or certify them.

EVIDENCE // CLAIM_BOUNDARY

Evidence before efficacy claims

Repository counts describe inventory and dogfooding activity. They do not prove that TRW improves outcomes on an independent workload.

Inspect the verification model

  1. Mechanism available

    LEVEL 1

    The repository contains the storage, recall, workflow, receipt, and handoff paths described here.

  2. Project use observed

    LEVEL 2

    TRW is used in its own repository. Inventory counts show activity and surface area, not efficacy.

  3. General outcome lift

    LEVEL 3

    Broad improvement across independent workloads remains an empirical question, not a marketing conclusion.

STATUS // AVAILABLE_SURFACES

What is available now

TRW is built by Tyler Wall with extensive AI-assisted implementation and review. The product boundary matters more than the mythology: the open framework, hosted platform, and proprietary tester surfaces have different availability and data paths.

AVAILABLE

Open framework

Installable and local-first. Persistent memory uses project-local storage; optional dense retrieval gracefully falls back when its extras are absent.

PUBLIC BETA

Hosted platform

Opt-in organization-scoped services and dashboards when configured. This is separate from the open framework’s local operation.

TESTER PROGRAM

Proprietary tools

Additional evaluation, orchestration, and research packages use a separate access path. They are not implied by the open install.

TERMINAL // TRY_THE_OPEN_FRAMEWORK

Start with one repository and one real handoff

Install the local framework, capture a meaningful project constraint, and verify that a later session can retrieve and re-check it.

OPEN QUICKSTART