Version 0.1 — Accepted (Standards Track)
Status: Accepted
Author: T81 Foundation Compiler Council
Applies to: Axion Kernel, T81VM, TISC, T81Lang
This RFC mandates that Axion MUST receive structured metadata describing loop annotations and enum guards so the Trace Subsystem (DTS) and Verification Subsystem (VS) (see spec/axion-kernel.md §1.1‑1.7) can reason about guard-aware execution. It ties that metadata into the Axion Policy Language (APL, RFC-0009) by requiring policies to reference the same trace descriptors and enumerated variant IDs.
Axion’s responsibilities (§1.1–§1.7 of spec/axion-kernel.md) highlight its central role for determinism, safety, and metadata hosting. Recent compiler cables already emit (policy …) loops for Axion, but match/enum guard events lack the same formal contract. Without a canonical payload (variant id, enum id, guard hit/miss, loop annotation) in Axion logs, deterministic auditing, guards, and policy enforcement cannot verify guard coverage or metadata hints. RFC-0009 introduces APL but does not prescribe what metadata must be paired with the policy. This RFC fills that gap.
Axion-aware compilers/CLI MUST embed two classes of metadata into the Axion trace payload stored in t81::tisc::Program:
(policy (loop (id …) (file …) (line …) (column …) (annotated true|false) (bound …))).(match-metadata (match (scrutinee Enum) (arms (arm (enum-id E) (variant-id V) (variant VariantName) ...)))).Every metadata record MUST include:
tier/allow-opcode semantics).include/t81/enum_meta.hpp) so Axion can reason deterministically about guards across compilations.Axion’s trace log (DTS) MUST receive events for Axion-aware opcodes such as ENUM_IS_VARIANT, ENUM_UNWRAP_PAYLOAD, OPTION_UNWRAP, RESULT_UNWRAP_OK, and RESULT_UNWRAP_ERR. Each event must:
AxionEvent.verdict.reason) describing enum/loop context (e.g., “enum guard enum=Color variant=Blue match=pass payload=i32”).This flow allows VS/CRS to correlate guard success with metadata obligations, verifying that no guard path is missing an arm (per spec axioms) and enabling Axion to deny transmissions that violate determinism (spec §1.1).
APL’s allow-opcode/deny-opcode clauses (RFC-0009 §2.2) now expect the same metadata naming and variant IDs emitted to the Axion log. Policy authors may reference (allow-opcode ENUM_UNWRAP_PAYLOAD) and assert that Axion logs must handshake with (match-metadata ...) entries for the referenced enum id/variant combos. This linkage assures that Axion’s Constraint Resolution Subsystem (CRS) and Recursion Control Subsystem (RCS) know whether guard coverage aligns with policy-level expectations.
Legacy binaries that lack match metadata continue to run; Axion treats the metadata as optional but logs warnings (DTS) and denies guard-specific policies. The compiler should emit warnings when metadata is missing. Tools like CLI/ir-inspector (see docs/guides/cli-toolkit.md) should expose metadata fulfillment.
t81::tisc::TypeAliasMetadata)?@bounded(loop(...)) require Axion to accept guard expressions as policies?