Question

What does "contract-driven" mean in Traverse?

Q: What does 'contract-driven' mean in Traverse?

Contract-driven means every capability has a machine-readable contract that is enforced at runtime, not just documented. The contract declares inputs schema, outputs schema, preconditions, postconditions, placement targets, and sandbox constraints. The runtime checks all of these before and after execution. You cannot call a capability with invalid inputs. You cannot place it on a target it does not support. This is different from OpenAPI or function definitions, which describe but do not enforce.

Contract-driven means every capability is defined by a machine-readable contract, and the runtime enforces that contract before any code executes.

This is not a documentation convention. It is not a type system. The contract is active policy. When a request arrives, the runtime reads the contract, validates the inputs, checks the placement target, evaluates the preconditions, and only then runs the WASM binary. If anything fails, execution stops and the caller gets a structured error, not a runtime exception from inside the capability.

What the contract declares

Inputs schema — the fields, types, and allowed values the capability accepts
Outputs schema — what the capability returns and its structure
Preconditions — logical conditions that must hold before execution starts, expressed over the inputs
Postconditions — guarantees that the output must satisfy after execution
Placement targets — the environments where this capability is allowed to run
Constraints — sandbox rules such as no network access, no filesystem access, or memory limits

How enforcement works

Before execution: the runtime checks inputs against the schema. It evaluates preconditions. It verifies the requested placement target is in the contract's allowed list. It checks that the sandbox constraints are satisfiable in the current environment. If any check fails, the capability does not run.

After execution: the runtime evaluates postconditions against the output. If a postcondition fails, the result is flagged in the trace artifact. You know immediately when a capability produced output that violated its own contract.

Every run produces a trace. The trace records the capability ID, the contract version used, the inputs, the outputs, every validation step, and whether each step passed or failed. That trace is a structured artifact you can inspect, store, and use for auditing.

Why this is different from OpenAPI or function signatures

OpenAPI describes an API. It does not enforce anything. You can call an endpoint with invalid data and the behavior depends entirely on the implementation. Function type signatures tell a compiler what types are expected. They do not express business rules like "the departure date must be in the future" or "the budget must be positive."

Traverse contracts express both structure and business rules, and the runtime checks both. A capability author writes the contract once. Every caller, every environment, every integration gets the same enforcement automatically.

Contract-Driven AI Development

The same principle applies to AI pipelines. When an AI agent calls a Traverse capability, it gets the same contract enforcement that any other caller gets. The agent cannot hallucinate an invalid input past the contract check. The trace artifact tells you exactly what the agent called, with what inputs, and what the capability returned. This is the foundation of Contract-Driven AI Development (C-DAD).