Harness families / Estimation, data and logic

Behavior

plannedPlanned. This family is a ratified entry in the harness-family taxonomy; its individual shape has not been ratified and nothing is implemented.

Status: PLANNED. This family is a ratified entry in the harness-family taxonomy. Its individual shape has not been ratified, and nothing is implemented. This page states scope and status; it is not a contract, and it does not imply parity with the Designed tier.

#Scope

Scripted or reactive decision logic that drives other families: rules, state machines, and responses to scenario conditions that decide what a vehicle attempts next.

#What exists today

Nothing. No schema, no header, no module, no open design task.

Behavior and scheduler overlap and may not survive as two families. Behavior decides what to attempt; the scheduler decides when it happens against constraints. If a freeze cannot draw that line crisply, one family is the right answer rather than two.

#What ratification requires

A family reaches Designed when an ABI has been drafted against a real consumer, and Shipped only when all of the following exist:

• A single .fbs schema as the source of the wire layout.
• A generated ABI header with size and offset locks, plus a drift gate that fails when the schema and the committed header disagree.
• Declared units and frames per field, named sentinels, and named negative error codes.
• A conformance kit carrying its own negative control, and a reference module.
• A stated tri-runtime parity envelope.
• Exactly one generic consumer port.

Until then, do not build against this family. If your work falls in this scope and cannot wait, build a records-in, records-out module through the BYO-wasm quickstart — that path needs no harness and is available now — and expect to migrate to the family ABI when it is ratified.

Source of truth for this page: docs/families/behavior.md. Regenerate with npm run build:docs.