Native Ready Reference Foundation

Native-Ready Reference Foundation

“Native-ready” describes the clarity of the current reference behavior. It does not mean that a native processor exists or that one is committed to the current roadmap.

Current state

Python remains:

• the implemented AISMixer runtime;
• the normative behavioural reference;
• the owner of the current data-plane semantics; and
• the basis for regression and future differential testing.

Campaign A made observable processing behavior explicit. Campaign B made state ownership, clocks, TTL boundaries, limits, lifecycle outcomes, and statistics explicit. Together, they reduce the amount of behavior that a future implementation would have to infer from incidental code structure.

Differential conformance surface

A future implementation could be compared with the Python reference through observable results:

Surface	Examples
Output	Ordered NMEA sentences and their outbound TAG metadata
Routing	Selected named target_id values for an accepted event
Deduplication	Global or target-scoped accept/suppress decisions
Assembly	Lifecycle status, ordered completion, and discarded keys
Metadata	Selected TAG s, minimum valid multipart c, and preserved or generated g
No-output behavior	Invalid input, pending fragments, conflicts, no-route results, and duplicate suppression
State inspection	Contract-relevant immutable statistics snapshots

The canonical behavioural contract defines the exact Python reference semantics.

Staged evolution

tested Python reference
        |
observable behavioural contract
        |
differential conformance
        |
possible future staged native processing

The last stage is explicitly future. The current Roadmap emphasizes staged process architecture and avoiding a single large rewrite; it does not commit to a native processor.

Current non-claims

• No native processor exists.
• No data-plane rewrite has occurred.
• No C or C++ API has been selected.
• No ABI has been defined.
• No binding or foreign-function technology has been selected.
• No benchmark, throughput, latency, memory, or other performance claim follows from Campaign A or Campaign B.
• No compatibility promise extends beyond the documented and tested behavioural surface.

Why the preparation matters

Explicit boundaries allow implementation work to be incremental:

• State can remain with its current owner until a deliberate boundary is introduced.
• A candidate implementation can be checked behavior-by-behavior rather than replacing the complete service at once.
• Routing, assembly, deduplication, metadata, and secure state have testable lifecycle edges.
• Injected clocks and deterministic generators make time- and ID-sensitive comparisons reproducible.
• Immutable statistics provide point-in-time state observations without mutating the system under test.
• Process separation can begin with coordinator, ingress, or egress responsibilities without requiring an immediate processing-language change.

The preparation is therefore an architectural option, not a feature claim.

Related pages

• Architecture Overview
• State, Lifecycle, and Limits
• Behavioural Contract
• Architecture Evolution
• Roadmap