Harness families / Estimation, data and logic

Scheduler

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

Ordering and tasking across a scenario timeline: when a maneuver fires, when a sensor is tasked, when a downlink is attempted, and how competing demands are resolved against constraints.

#What exists today

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

A scheduler is a decision family, not a physics family, and its contract is dominated by determinism: the same inputs must produce the same schedule in every runtime, which makes any use of iteration order over unordered containers a defect rather than a detail.

#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/scheduler.md. Regenerate with npm run build:docs.