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. Campaign C then established the implemented representation boundary: immutable IngressFrame transport, explicit PayloadTextMode, bytes-native scanning into immutable half-open spans, parse-once ParsedSentence metadata, and production entry through feed_parsed_outcome().

That production entry shares one lifecycle implementation with the supported legacy string feed_outcome() API. The Python assembler still materializes and stores sentence strings, and forwarding output remains string-based. Together, the three campaigns reduce the behavior that future work would have to infer from incidental code structure.

Differential conformance reference points

The tested Python behaviour exposes observable reference points that a future implementation could compare. They are not yet a stable processor contract or formal differential-conformance surface:

Surface	Examples
Output	Ordered NMEA sentences and their outbound TAG metadata
Representation	Direct frames, valid legacy-event adaptation, scanner spans, and parsed metadata
Routing	Selected named target_id values from the one snapshot and optional frame.source_id match for an accepted frame
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. A stable processor contract would have to be defined before it could serve as an API, ABI, or native implementation boundary. The current Roadmap does not commit to a native processor.

Current non-claims

• No native processor exists.
• No stable processor API or ABI has been defined.
• No C or C++ API has been selected.
• No binding or foreign-function technology has been selected.
• The assembler and forwarding output are not bytes-native.
• End-to-end zero-copy processing is not claimed.
• No benchmark, throughput, latency, memory, or other performance claim follows from Campaign C.
• No multiprocessing processor or worker architecture is implemented.
• 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.
• Any future process separation would require separately specified ownership, supervision, and IPC boundaries; Campaign C did not introduce them.

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

Related pages

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