Harness families / Event physics

Effects

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

The visual and volumetric consequences of an event-physics family: explosion volumetrics, particle systems, debris rendering, and the timing that ties them to the event that caused them.

#What exists today

Nothing as a module-SDK family contract.

This is the one family in the taxonomy whose output is explicitly presentational. That makes it a scene-writing family by definition, which means it will need the full shared-memory harness treatment rather than the records-in, records-out shape that suffices for most compute families.

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