Harness families / Environment and interaction

Environment

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

Ambient models that other families query rather than invoke directly: atmospheric density, gravity field, magnetic field, solar and radiation environment, and space weather indices. A propagator asks the environment for density; it does not carry its own atmosphere.

#What exists today

Nothing as a family contract.

This family is the clearest case for a query-shaped ABI rather than a compute-shaped one: many callers, small requests, high call frequency, and a strong requirement that two callers asking the same question at the same epoch get bit-identical answers.

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