yesod.work

Concept · the general task model

A task does not need a merge
to need a factory.

Yesod gives code work and non-code work the same control shape: a durable request, a bounded contract, accountable execution, explicit verification, and an inspectable outcome. What changes is the evidence carrier.

One control model · two carriers

The line forks at the work product, not at the controls.

  1. 01

    Request

    A durable identity, objective, requester, and intended outcome enter the line.

  2. 02

    Acceptance contract

    Scope, owner, boundaries, verification gates, and required evidence become explicit.

  3. 03

    Bounded execution

    The assignee acts within the named systems, permissions, budget, and stop conditions.

Commit-bearing code path

  1. 04A

    Commit

    A reviewable diff and immutable source revision carry the implementation.

  2. 05A

    Verify

    Checks and review test the candidate against the acceptance contract.

  3. 06A

    Admit by merge

    The verified candidate joins the repository through its controlled merge boundary.

Evidence-bearing outcome path

  1. 04B

    Produce evidence

    A source snapshot, artifact, receipt, applied-state record, or decision record carries the work.

  2. 05B

    Verify

    A named check establishes provenance, completeness, and the result against the contract.

  3. 06B

    Admit the outcome

    An authorized publication, application, or decision gate accepts the verified result.

07

Durable ledger

Request, Yesod note, Beads, lifecycle, gates, evidence, and outcome return to one inspectable record.

Both paths start with the same bounded request and acceptance contract, pass through explicit verification, and finish only when the evidence and outcome are attached to the durable ledger.

The common contract

Controls follow the claim.

The request says what should become true. The acceptance contract says what would prove it. Execution does not get to redefine either after seeing the result.

Objective
The observable change the request is trying to produce—not the activity of running an agent or asking someone to look.
Acceptance contract
The conditions, boundaries, required evidence, verification method, and failure states agreed before execution.
Ownership
The requester owns intent; the task owner owns the contract; the assignee owns execution; the named gate owns admission.
Lifecycle
The public work record follows request, plan, build, verify, and release, whether release means merge or outcome admission.
Evidence
The inspectable records that support the claim: revisions, artifacts, sources, receipts, snapshots, checks, and decisions.
Durable outcome
The accepted result, its status, and its evidence attached to the same Yesod note and Bead plan that carried the request.

Different carrier, equal burden

Merge is one admission gate.

A commit can identify a code candidate. It cannot prove a recommendation, a provider-side change, a published artifact, or an authorized decision. Those need evidence native to their outcome.

How code work and outcome work satisfy the same control questions
Control questionCommit-bearing codeEvidence-bearing outcome
What changed?Reviewable diff at an immutable source revisionArtifact, source snapshot, receipt, applied state, or decision record
What was bounded?Repository, branch, files, dependencies, and allowed behaviorSources, target system, permissions, time, spend, and stop conditions
What verifies it?Checks, review, security policy, and deterministic candidate gateReproduction, reconciliation, read-back, independent observation, or policy review
What admits it?Verified merge into the durable source recordNamed publication, application, approval, or decision boundary
What persists?Commit, merge, check results, release state, and linked outcomeEvidence bundle, gate result, outcome status, owner, timestamp, and limitations

Six non-code examples

Evidence should fit the outcome.

The examples are deliberately concrete. Each names what would count, how it would be checked, and what returns to the public or private durable ledger.

  1. Research

    Choose a trace store that meets the approved retention and export requirements.

    Acceptance contract
    Compare named options at a pinned date against retention, access, export, security, and cost criteria.
    Required evidence
    Primary-source citations, capture dates, a comparison artifact, assumptions, and reproducible calculations.
    Verification
    A reviewer resolves the cited sources and recomputes the claims that drive the recommendation.
    Durable outcome
    A reviewed report and decision record, linked to the originating Yesod note.

  2. Configuration

    Apply an approved domain-security policy without breaking the public endpoint.

    Acceptance contract
    Name the target state, account and zone boundary, change window, rollback condition, and propagation checks.
    Required evidence
    Change request ID, provider receipt, sanitized before-and-after export, timestamps, and endpoint probes.
    Verification
    Independent DNS and HTTP observations match the intended state; rollback remains possible.
    Durable outcome
    An applied-state revision and evidence bundle recorded in the durable ledger.

  3. Publication

    Publish one immutable book edition at its canonical public URL.

    Acceptance contract
    Fix the artifact digest and size, destination, metadata, visibility, receiver behavior, and reader checks.
    Required evidence
    Upload receipt, read-back SHA-256, receiver run, edition metadata, review decision, and public URL.
    Verification
    Re-download and hash the object, resolve the canonical URL, and confirm the manifest matches it.
    Durable outcome
    A durable edition entry and retrievable artifact—not merely a successful upload claim.

  4. Catalog

    Publish a current, normalized model catalog for approved factory reports.

    Acceptance contract
    Require stable identities, reviewed aliases, named source ownership, freshness dates, and schema conformance.
    Required evidence
    Pinned vendor sources, generated catalog diff, validation output, rejected aliases, and content digest.
    Verification
    Regenerate the catalog, run schema and link checks, and review provenance before publication.
    Durable outcome
    A versioned catalog snapshot whose scope and expiry remain visible.

  5. External operation

    Change a CDN rule in the intended account and confirm its observed behavior.

    Acceptance contract
    Limit the target, authorization scope, idempotency key, success signal, stop condition, and rollback path.
    Required evidence
    Operation ID, provider response, before-and-after state, audit event, and external probes.
    Verification
    Reconcile the receipt with current provider state and an observation outside the control plane.
    Durable outcome
    A confirmed external state transition with its operator and rollback record attached.

  6. Decision

    Postpone a roadmap item without losing why, who, or when it returns for review.

    Acceptance contract
    Name the authorized decision owner, options, criteria, affected records, review date, and reopening trigger.
    Required evidence
    Source inputs, decision record, authority, rationale, dissent or uncertainty, and linked roadmap state.
    Verification
    Check that the inputs resolve, the owner had authority, and every affected record carries the same decision.
    Durable outcome
    A durable postponed state with a reason and revisit condition—not a disappearing conversation.

No merge does not mean no controls

An assertion is not an evidence bundle.

A human can authorize a judgment or approve an outcome when the contract assigns that role. “I checked it” still does not replace the artifact, source, receipt, state capture, or reproducible check the contract requires.

  • Keep lifecycle states literal. Work is planned, in progress, in review, completed, blocked, or cancelled; a gate is pending, running, passed, failed, or not applicable.
  • Keep evidence states distinct. A source record, derived summary, redaction, and missing evidence are not interchangeable.
  • Fail visibly. If the required evidence cannot be produced or verified, the work remains blocked, failed, or not shipped; it does not become complete by narration.
  • Close the loop. The outcome and its limitations return to the originating request, Yesod note, child Beads, and durable ledger.

Inspect the model in use

The factory is the lifecycle, not the merge button.

Use the work ledger for request-to-outcome state and evidence traces for the source, derived, redacted, or missing records behind a completed public claim.