Create a contract

A contract defines a thread’s steps, owners, prerequisites, and content checks. Its Gherkin-style source compiles into deterministic rules; no AI interprets them.

A complete contract

Save this as refund.feature:

Feature: refund_review
Version: 1
Description: Approve and record a valid refund.

Step: "approval"
  Description: "The processor approved the refund request."
  Required context: "reference" means "Original payment reference."

Step: "refund"
  Description: "The processor recorded the completed refund."
  Required context: "reference" means "Original payment reference."
  Required context: "amount" means "Amount refunded."
  Required context: "currency" means "Currency of the refund."
  Required context: "receipt" means "Refund receipt identifier."
  Optional context: "note" means "Additional refund explanation."
  Optional context: "processor_reference" means "Processor reference when available."

Rule: Approve the request
  When step "approval" is submitted
  Then owner must be "processor"
  And this step is an entry point
  And content "reference" must not be empty

Rule: Record the refund
  When step "refund" is submitted
  Then owner must be "processor"
  And step "approval" must have succeeded
  And content "reference" must equal approval.reference
  And content "amount" must be a number greater than 0
  And content "currency" must be one of "GBP", "USD", "EUR"
  And content "receipt" must match regex "^RF-[0-9]{8}$"
  And this step is terminal

Feature names the contract. A Step block describes a step’s business meaning and registers the context fields the Engine may use. Add one Required context: or Optional context: line for each field; repeat either line type to register multiple fields. Required context must be present; optional context can be absent. A field meaning after means is an optional classifier hint. Duplicate fields or conflicting required and optional declarations fail validation. Each Rule defines the executable checks for one matching step, and all its clauses must hold. Only the supported vocabulary is accepted.

Parallel steps

If two or more defined steps can run in parallel, add a Group that lists their step names:

Group: "parallel_reviews"
  Given parallel steps are "fraud_review", "stock_review"
  And all parallel steps must succeed
  And combined duration must be within "5m"

Each member needs its own Rule; a Step block supplies business meaning and context for classification. The group needs at least two distinct members; the success and duration clauses are optional. If a later step needs both reviews, declare both as prerequisites in its Rule:

  And step "fraud_review" must have succeeded
  And step "stock_review" must have succeeded

Preview and create

In the dashboard, open Contracts and use the contract editor. Or use the CLI:

threadify-cli contracts preview --file refund.feature
threadify-cli contracts create --file refund.feature

Preview checks the contract and displays its compiled structure without saving. To update, increase Version and run:

threadify-cli contracts update --id CONTRACT_ID --file refund.feature

Use .feature for contracts.

Common clauses

Clause	Purpose
`owner must be "processor"`	Identify the party allowed to report the step
`step "approval" must have succeeded`	Require a previous successful approval
`step "approval" must succeed before each invocation`	Require fresh approval for each attempt
`this step is an entry point`	Allow the workflow to start here
`this step is terminal`	Complete the thread after successful validation
`next step must be one of "refund", "cancel"`	Declare strict immediate transitions to defined steps
`this step must finish within "30s"`	Validate the recorded step duration
`content "reference" must be present`	Require a field, allowing an empty value
`content "reference" must not be empty`	Require non-whitespace text
`content "amount" must be a number greater than 0`	Check a numeric bound
`content "currency" must be one of "GBP", "USD"`	Check allowed values
`content "approved" must be a boolean`	Require `true` or `false`
`content "receipt" must match regex "^RF-[0-9]{8}$"`	Check text against a regular expression

Dependencies allow intervening work. Once you use explicit next step rules, declare every allowed immediate transition. These are different flow policies. See the complete rule vocabulary for timeout, retry, and thread-wide clauses.

Content and earlier steps

Content checks read the context added to a step. Values are represented as strings. Dotted field names are literal keys, not nested paths. An unquoted approval.reference reads the same thread’s latest validated successful approval. A quoted "approval.reference" is literal text. A cross-step reference also implies a dependency. Missing data or unavailable state rejects the submission; Threadify does not silently use an older value. Regex matching uses Go’s RE2-style syntax. Use ^ and $ for a whole-value match. Lookaround and backreferences are unsupported. Double backslashes in quoted Gherkin strings, or use [0-9] rather than \d. Invalid patterns are rejected during preview and creation.

Validation timing

Content and owner checks can reject a submission before recording it. Flow, prerequisite, retry, and timing validation uses asynchronous workers; an acknowledged event can later be marked violated. Use execution waits for permission before an action or to wait for the exact validation result after reporting it.

Getting Started

Core Concepts

Integrity and access

API Reference

A complete contract

Parallel steps

Preview and create

Common clauses

Content and earlier steps

Validation timing

​A complete contract

​Parallel steps

​Preview and create

​Common clauses

​Content and earlier steps

​Validation timing

A complete contract

Parallel steps

Preview and create

Common clauses

Content and earlier steps

Validation timing