The Builder Guide

Plays, runs, and playbooks

A play is one verifiable piece of work on offer. Its identity is its acceptance contract: the exact, checkable definition of done. You browse plays, and each one has a plain title shaped around the result you want.

A run is one commissioned execution of a play. When you run a play, that creates a run, and the run appears under My runs, where you follow its state through to delivery.

A playbook is a situation and the plays it comprises, shown as an ordered path when order matters. Recognize the situation you are in, and the playbook shows the work it takes, including the parts that are easy to miss.

Commissioning and credits

To commission a play, open it and use Run. You fill in the play's intake (the fields that make its acceptance contract specific to you), and your credits are held until verified delivery.

Credits are the unit of cost. A plan refreshes a monthly pool of credits, and a pack is a one-time top-up. Each play shows its cost in credits: that figure is what is held when you commission a run, then spent only on verified delivery.

STUD is in a soft launch, so paid commissioning is not open yet. Plays that are ready show Opens soon rather than a live checkout, and you can join the waitlist to be told the day it goes live.

Verification and the acceptance record

Every play settles against its acceptance contract, never against an opinion. Here is what that check is, and the exact vocabulary it uses.

What an acceptance check is

How a result is checked depends on the play's verification class:

Automated check against your inputs

A deterministic program checks the result against your inputs. The run settles only when every rule passes.

Verified against a live signal

The result is checked against a real external signal (for example, a live endpoint's response) within a stated bound.

When a play's contract states a knowingly simplified check, that scope is written in plain language on the play page under What's verified, so it is honest at the point of sale.

What a deliverable interface is

A deliverable interface is the exact vocabulary an automated check enforces: the keys a document must carry, the tokens and literals it recognizes, and the entry points a program must expose. It is generated from the verification source, never hand-written, so it always matches what actually runs.

A worked example

Take the play Targeted prospect list, which settles by validating a lead list as data. Its interface publishes:

Tier

doc-validator (the result is a document, checked as data).

Document keys

email, name (every row must carry these fields).

Checks

valid_email, required_name, no_empty_rows, deduped_emails, row_count, format_parses (each one must pass).

Your parameters

count, format (how many contacts, and csv or json: you set these at intake, and the check then holds the result to them).

Deliverable label

lead_list (the name of what you receive).

So before commissioning, you know exactly what defines an accepted lead list: the right fields, valid and deduped emails, and the count and format you asked for.

Where to see the interface for a specific play

This Guide teaches the interface with one worked example. For any specific play, the plain-language What's verified line on its page states how that play is checked, and the full machine interface is part of that play's published acceptance contract, generated from the same verification source shown above.

Your deliverable

When a run is accepted, you receive its output: the concrete result the play produces, generated for your inputs. The run view carries the deliverable and shows its state through to Delivered.

Some plays show an example on their page, so you can see the shape of what you receive before you commission. Your own result is always generated for the inputs you provide.

Your workspace

A workspace is your per-venture context: the facts you state once (and can revise), the runs you commission, and the pre-fill that carries your context into each play's intake. If you run more than one venture, each is its own workspace, and switching the active workspace switches every context together.

When a play's intake asks for something you have already stated, the field is pre-filled from your workspace facts, with where it came from shown, so you confirm rather than retype. A default workspace is created for you the first time you need one, so a single-venture buyer never sees the ceremony.

As you work, STUD can propose facts for you to confirm, rather than writing anything silently. One tap promotes a proposal to a stated fact, and declining is an equal, kept choice. Nothing replaces a value you stated without showing you first, and a replaced value stays recoverable.