Design Principles

The Node Manifest schema evolves under a small set of explicit principles. These guide both field design and versioning.

The first principle is platform-agnosticism. The manifest must apply to air, maritime, land, and space nodes without embedding platform-specific quirks. Anything that depends on a particular airframe, hull, or vehicle class belongs in separate integration layers, not in the core manifest.

The second principle is a minimal core with extensions. The core stays small and stable, while vendor- or domain-specific detail lives in extension sections or separate profiles. The schema explicitly allows unknown top-level fields so that experimentation can proceed without destabilising the core.

The third principle is deterministic semantics. Fields must have clear, testable meaning and avoid ambiguous interpretation. Where behaviour depends on time, identity, or ordering, the specification defines exact tie-breakers so that different consumers arrive at the same answers when given the same inputs.

The fourth principle is explicit versioning. The schema uses semantic versioning from the start, and every manifest carries a schemaVersion. The 0.x line is pre-stable: breaking changes are allowed but must be intentional and documented. Once the schema reaches 1.0.0, changes that break existing manifests will require a new major version.

The fifth principle is separation of concerns. Mission semantics belong in the manifest, while runtime implementation details stay in the execution system. The manifest says what is allowed and obliged; runtimes decide how to implement that contract within their own architectures.

In the 0.2.0 schema line the manifest defines a stable envelope (schemaVersion, kind, manifestId, nodeId, issuedAt, and an optional validity window), a minimal tenancy block naming which tenants the manifest is intended to serve, a mission block that captures mission identity, window, and region, and a profile/contracts block that names the profile, runtime ABI, and policy bundles used at compile time. All other mission content is intentionally left for later versions. Producers and consumers are expected to ignore top-level fields they do not understand. The normative semantics of the envelope fields and the manifest selection rules are defined in spec/ENVELOPE-v0.2.0.md, the semantics of the tenancy block are defined in spec/TENANCY-v0.2.0.md, the semantics of the mission block are defined in spec/MISSION-v0.2.0.md, and the semantics of the profile/contracts block are defined in spec/CONTRACTS-v0.2.0.md.