Docs/Concepts
Source guide3 min read

Model inputs, outcomes and failures

Make the data boundary explicit while keeping business meaning in the operation and handler.

Download Markdown ↓
Source and verification context ⌄

Source-guided

Inspect the source ↗

Repository links may require access. Source inspection is separate from a clean public-package installation.

AN INTERACTIVE READING MAP

Get the shape of this guide.

Move through the ideas, inspect their relationships, or make a focused reading path. The complete guide stays below.

READING SEQUENCEUnderstand how the ideas connect
Choose a point to look closer
01 / Guide section

Describe what the caller must supply

An input schema should express the shape you actually accept, including required values and constraints that can be checked before execution. Keep the distinction between an absent value and a valid empty value clear.

Read the supporting context

OperationSpec separates the main input from optional transport-related parameter, query and header models. Inspect the adapter's mapping before assuming a field is read from a particular part of a request.

Explore a section, then continue with the complete article below.

1 / 4

Describe what the caller must supply

An input schema should express the shape you actually accept, including required values and constraints that can be checked before execution. Keep the distinction between an absent value and a valid empty value clear.

OperationSpec separates the main input from optional transport-related parameter, query and header models. Inspect the adapter's mapping before assuming a field is read from a particular part of a request.

Describe what the caller may rely on

The output model tells callers what a successful handler must return. Use a stable shape that reflects the product outcome rather than leaking the entire response from a provider.

Output validation detects a mismatch after the handler returns. It helps identify a broken boundary, but the host still owns the transaction or recovery behavior of effects that have already happened.

Choose the check that answers the question.Examine the support · 3 ways to look closer

One green check cannot establish every boundary. Connect the intended claim with the smallest observation that can support it.

What do you need to establish?
A CLAIM TO EXAMINE

Observe a denied call through the real entry point.

The operation explicitly requires approval, and the request otherwise has valid input.

What it supports

A disposable counter or fake outbox can reveal whether the handler was entered.

What it leaves open

A hidden button or mocked always-allow verifier cannot establish the guard.

WHAT WOULD HELP YOU DECIDE

Omit the required receipt, inspect the adapter’s canonical failure and verify the effect remains untouched in your actual test.

Where this explanation comes from

An authored situation, grounded in the linked source guides. Choosing a case explores its expected responsibilities; it does not execute an operation.

Give expected failures names

The model supports typed success and failure catalogs as well as compatibility error declarations. Use expected failures to describe product cases that a caller can handle, such as unavailable resources or a rejected transition.

The registry's executeResult path carries a canonical result and normalizes failures with operation and trace context. Adapters project that result into their own protocol. Avoid making clients inspect an incidental human error string as their primary control flow.

Kind of outcomeCaller concernWhere to investigate
Invalid requestCorrect the submitted dataInput schema and mapping
Expected business failureChoose another valid product actionDeclared result and handler
Denied executionSatisfy an authorized policy or approval pathHost decision context
Invalid handler outputReport or repair an implementation defectHandler and output model

Use examples as boundary fixtures

Keep a representative input and result near the operation and use them in the guide and the test. Include one failure case that demonstrates the reason the constraint exists.

When you change a required field or named outcome, review clients and docs together. Matching TypeScript imports alone does not show whether a deployed caller still sends the old wire shape.

See it in an example.

UI / Intermediate

Capture now, complete when ready

Build an interface

Use form contracts to accept a minimal intake while keeping missing readiness fields visible.

  1. Choose the form contract
  2. Inspect minimal intake
  3. Inspect conditional validation

Source demonstratesThe inspected fixture separates acceptance from completion status.

Does not demonstrateProduction form storage, submission delivery, or authentication.

Inspect the walkthroughBehavior · proof and limits · source checks

Follow the source behavior

A customer intake can begin with a name. In the fixture, a quick capture is accepted while email, phone, and consent remain completion debt. A richer profile can then determine whether the record is ready for the next workflow.

  1. Choose the form contract

    Inspect all-fields, progressive-steps, and customer-projection forms. The package includes field kinds, conditional rules, sections, and step layouts.

  2. Inspect minimal intake

    The quick-capture fixture contains a customer ID and display name. The smoke test expects capture to succeed and completion to remain incomplete with email, phone, and consent debt.

  3. Inspect conditional validation

    Another test builds Zod validation with relations and expects a missing repeated contact value to be reported at contacts[0].value.

  4. Use the public proof map

    The proof-config export lists docs, sandbox, forms, and UI entrypoints. Adapt through the supported exports, then supply your own persistence and submission behavior.

What this example establishes
Source demonstrates
  • The inspected fixture separates acceptance from completion status.
  • The source tests inspect field coverage, step layout, conditional validation, and public exports.
  • The public preview is deterministic fixture state with no required backend or credentials.
Does not demonstrate
  • Production form storage, submission delivery, or authentication.
  • A production renderer for every host application.
  • A PII hint automatically implementing a privacy control.
Reproduce the source checks

The source assertions cover quick-capture acceptance, incomplete readiness, conditional validation, and supported public entrypoints.

Working directory examples/form-showcase

bun run smoke

Commands and tests inspected; not executed here.

Continue from here.

Start

Read your first operation

3 min read

Trace a maintained contract from its input schema to its deliberately small handler.

Look inside the guideOpening context · complete reading path

What this walkthrough demonstrates

The maintained minimal example declares an operation named user.create. It accepts an email and returns the same email. Despite the operation's name, the shown handler does not create a persistent account, send a message or call a provider.

Work through the guide
Guides

Expose one operation through API and MCP

3 min read

Share the registered behavior while keeping authentication, transport formats and evidence explicit.

Look inside the guideOpening context · complete reading path

Start from one registry

Register the operation and bind its handler once. The REST createFetchHandler and MCP registerMcpTools implementations both call OperationSpecRegistry.executeResult. That shared invocation path is the useful connection between an API request and an agent tool call.

Work through the guide
Operations

Test the promise at the boundary

3 min read

Choose checks that establish meaningful behavior, including denied effects and real consumer imports.

Look inside the guideOpening context · complete reading path

Give each test one question

An operation has several boundaries, and one green check cannot answer every question about them. Separate declaration validity, business behavior, adapter behavior and external consumption so failures tell you where to look.

Work through the guide
Next: Expose one operation through API and MCP →
Your view

Make room for your context.

Shape the presentation around this moment. You can change it whenever you need.

Your context

The different parts of you

Choose a starting point

A useful mix of context, visuals and gentle guidance.

Tune each dimension
Each dimension can change independently. Product permissions and available actions stay unchanged.

Support the way you begin and return

Tune your support

Reading comfort

Choose your language

Interface language changes text only. Markets, prices and workflows keep their own settings.

Translation coverage

Original source

Navigation151
Graph616
Categories378
Portfolio833
Examples2,035
Source preview1,542

More translations will be added as content is reviewed.

This preference is saved on this browser.

Search the website

Useful starting points

No results. Try a shorter phrase, an operation name or another search area.

A LITTLE ROOM TO EXPLORE

Find something to explore.

Open a closer look on this page, try a different perspective, or follow the detail into its own page.

How previews and controls work
01

Look before you leave

Hover a link or focus it with Tab to see a preview. Clicking the original link or pressing Enter always opens its destination.

02

Stay with the context

Move into the preview to explore its sections. Use Alt + ↓ from a focused link to enter it with the keyboard. Escape closes it.

03

Open the possibilities

Disclosure rows, perspective choices and highlighted controls reveal more. Your view changes reading comfort and the context you explore.

A separate button for a closer look

Show small preview buttons beside links where there is room. Tap the eye to inspect, or tap the link to go straight there. This choice stays in this tab.

No browsing history is collected. Reduced motion follows your device and Your view.