Contract authoring

Contract authoring is expressing intent by composing requirements. A contract states those requirements and the context needed to interpret and apply them.

Reusable contracts provide the building blocks. Composition determines how their requirements apply together. For example, a funding-view contract can use a reusable source-gathering contract while requiring every reported event to cite a source. Supplying inputs and connecting contracts makes that request concrete; it does not by itself establish that the result is accurate.

Execution and evaluation

An agent performs the work, and an evaluator assesses whether the contract's requirements are satisfied. The executor performs the work and returns a result that includes the evidence needed for assessment. The evaluator returns an assessment: its findings about the contract and the evidence. Execution and evaluation repeat as needed. Evaluation can also assess the current state before further execution.

These are roles. The same agent can perform both unless a composed contract requires independence. A decision model can perform evaluation. Authors compose contracts for evidence, review and authorization just as they compose contracts for the rest of the work.

A result can be a long document containing or referencing artifacts and records. Keep its references accessible to the evaluator. Evidence belongs in the result, not in a separate return value. Fulfillment means satisfaction of the contract's applicable requirements; returning a result does not establish fulfillment by itself.

Use out for the normal result channel and error for execution failure. An evaluator can return a normal assessment that finds unmet requirements or insufficient evidence in its subject. Preserve partial work and effects when execution fails. These concepts map to the selected runtime's existing interfaces: function returns, responsibility state and receipts, and declared errors. They do not add syntax or prescribe operating-system streams.

Requirements and approaches

A requirement states a condition the work must satisfy. An approach describes how to satisfy it. A constraint limits permissible actions or results. A required step is also a requirement, even when other choices remain open.

Standing requirements, such as keeping a funding view current, are one use case. Requirements can also apply to a single deliverable, an action before publication, or evidence needed at completion. Choose the supported contract kind and sections for the work rather than treating every request as a continuous service.

Reuse and composition in this format

These docs cover the public skill's Contract Markdown and ProseScript format. It provides several concrete ways to reuse and combine contracts:

• A function declares ### Parameters and ### Returns; a caller supplies inputs and invokes it with call.
• A responsibility subscribes to another contract's published facets through ### Requires and ### Maintains. Forme resolves those connections.
• A pattern describes reusable coordination with slots and configuration; compilation specializes it into nodes.

These mechanisms combine declared interfaces and behavior. A link to a file alone does not create a subscription, provide a tool, or grant permission. Check that connected requirements and interfaces are compatible. The Contracts and ProseScript references describe the actual syntax; this introduction adds no new section names or operators.

Keep requirements in the authored source

The authored contract is the reference for what the agent is asked to do. Compiled artifacts and diagrams must preserve its meaning. Keep supplied inputs, environmental capabilities, and execution records distinguishable from the requirements themselves.

Changing a procedure does not remove a requirement it was meant to satisfy. When requirements change, revise the source explicitly and use the version selected for the run. A previous result is evidence about that run, not proof that revised requirements are satisfied.

Standing work and the world-model

A responsibility maintains a world-model: structured state that persists between renders. Its ### Maintains section describes the state, material changes, named facets, and postconditions. The world-model records the agent's view of the world; its contents still need the evidence required by the contract.

A render is a bounded attempt to produce the next state:

(contract, evidence, prior world-model) -> (new world-model, receipt)

The contract states the requirements. Evidence informs the attempt. The new world-model and receipt record its result. Running a render, producing a receipt, and satisfying the requirements are distinct outcomes.

The host determines how subscriptions, freshness checks, and receipts operate. Continuous operation requires a serving host; writing a standing requirement does not start a background service. See Harness-agnostic for capabilities and implementation limits.

Requirements and evidence

Declared inputs, outputs, and postconditions help callers understand a contract and assess its results. Deterministic checks can establish some properties; semantic claims may rely on an agent's assessment. A self-attestation is not independent verification. Use the evidence and checks the requirement calls for, and report unmet requirements or uncertainty explicitly.

What you actually write

This example states requirements for a funding view. It illustrates a standing contract in the documented format:

---
name: competitor-funding
kind: responsibility
---

### Goal

Keep a current, corroborated funding view for every tracked competitor.

### Maintains

A funding view per competitor: each carries a stable `name`, a set of funding
events (round, amount, date), and a `last_corroborated` field. Material: the
event set (unordered) and each event's round, amount, and date. Immaterial
everywhere: `fetched_at` and source request ids. Postcondition: every funding
event cites a source.

The postcondition requires a source for every event. The absence of ### Execution leaves the agent to choose its approach within the applicable requirements. This fragment does not configure data access or an ongoing wake source; a serving setup must provide the inputs and continuity policy needed for the requested freshness.

When specific actions or their order are required, express them in ProseScript under ### Execution. Required steps remain part of the contract. Use ### Invariants for applicable limits, and distinguish stating a limit from the host's ability to enforce it.

Where to go next

These docs are orientation. The canonical execution behavior lives in the public open-prose skill. Follow the syntax and semantics of the version installed for your run.