Alpha Observability Standard#

AOS 1.0 — Draft 1#

Date: 22 September 2026
Status: Proposed project standard and implementation contract. This is not a claim of an existing implementation, external ratification, or completed qualification.
Intended implementer: Claude Code or another engineering agent working in the Alpha repository.
Scope: The complete observation architecture, from source and compilation through native execution, learning systems, distributed operation, persistence, investigation, and evidence validation.

Alpha MUST be able to explain the origin, execution, resource use, measurements, failures, and retained evidence of any supported computation, at explicitly declared cost and coverage, without making an external observability service part of that computation's correctness path.

This standard defines semantics, required behavior, boundaries, and acceptance criteria. It deliberately leaves algorithms, package decomposition, native layouts, internal storage engines, scheduling, and user-interface design to the implementer. It does not prescribe a sequence of implementation tickets.

“Complete architecture” means that every architectural concern has a place in the model and a declared capability boundary. It does not mean recording every operation, recovering unobserved information, or pretending unsupported hardware measurements exist.

Contents#

1. Normative language and authority
2. Scope, principles, and implementation freedom
3. Architecture and dependency boundaries
4. Conformance and capability declarations
5. Identity, entities, and execution lineage
6. Values, schemas, and evolution
7. Observation envelope and epistemic status
8. Context, activities, state transitions, and relations
9. Time, order, and clock correlation
10. Coverage, completeness, and data loss
11. Capture policy, budgets, and admission
12. Producer API and hot-path behavior
13. Compiler integration and static provenance
14. Runtime, scheduler, and resource observation
15. Accelerator and device observation
16. Numerical and tensor observation
17. Learning, experiments, and evaluation
18. Distributed, service, and agent execution
19. Diagnostics, failures, and incident capture
20. Recording channels and buffering
21. Persistent journal and durability
22. Artifacts, checkpoints, and reproducibility
23. Native encodings and interchange
24. AOS-JSON/1 reference interchange
25. Ingestion, transport, and synchronization
26. Indexing, aggregation, retention, and deletion
27. Query and investigation contract
28. Presentation and agent-facing interfaces
29. Security, privacy, and trust boundaries
30. Validation, proof, and evidence receipts
31. Performance, overhead, and noninterference
32. Observability of the observer
33. Deployment and operational behavior
34. Migration and compatibility
35. Conformance tests and qualification
36. Required implementation deliverables
37. Domain schema catalogue
38. End-to-end reference scenarios
39. Implementation charter
40. External references

1. Normative language and authority#

AOS-NORM-001. Uppercase MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY carry the requirement meanings of BCP 14, RFC 2119 and RFC 8174 [N1, N2]. Lowercase uses are ordinary prose. SHOULD deviations require a recorded rationale and consideration of the consequences. A MUST deviation is a conformance failure, not merely a design preference.

AOS-NORM-002. Requirements apply to the component and capability that claim them. A file reader does not need a GPU; a GPU recorder does not need to implement a web server. Every deployed composition MUST identify the profiles and capabilities it actually provides.

AOS-NORM-003. Tables labelled required, field requirements, and state-machine rules are normative. Examples, suggested command names, and proposed paths are illustrative unless explicitly stated otherwise. Pseudocode is not a promise of existing Alpha syntax.

AOS-NORM-004. Repository rules for ownership, effects, target admission, proof erasure, native lowering, and qualification remain authoritative. An implementation MUST reconcile this standard with the current repository rather than assuming a previous source snapshot is still current. A real incompatibility MUST be reported and resolved explicitly; it MUST NOT be hidden with a fallback or fabricated receipt.

AOS-NORM-005. This standard's version, schema versions, encoding versions, and implementation releases are separate identities. Conformance to AOS 1.0 does not imply that an implementation has a particular ALPHATEL byte-layout version.

2. Scope, principles, and implementation freedom#

2.1 Covered concerns#

AOS-SCOPE-001. The architecture MUST accommodate source resolution, elaboration, checking, proof processing, transformations, representation changes, code generation, linking, artifact construction, runtime evaluation, scheduling, memory and resource ownership, device submission, data movement, synchronization, numerical behavior, learning, inference, evaluation, persistence, distributed work, diagnostics, failures, and observability-system health.

AOS-SCOPE-002. A new learning algorithm, execution model, device, or compiler representation MUST be addable through versioned schemas and providers without requiring every reader or producer to understand that domain. Core models MUST NOT assume CUDA, NVIDIA, transformers, gradient descent, request/response services, or a single host thread.

2.2 Fundamental invariants#

AOS-CORE-001. Observations MUST distinguish intended work, submitted work, observed completion, validated result, and inferred explanation. None implies the next without appropriate evidence.

AOS-CORE-002. Static meaning SHOULD be retained once and referenced cheaply at runtime. Large data MUST be separable from the high-frequency event stream.

AOS-CORE-003. Capture cost, coverage, loss, uncertainty, redaction, and unsupported capabilities MUST be representable and queryable. A reader MUST NOT silently replace missing information with successful outcomes, zeros, or invented times.

AOS-CORE-004. Optional observation MUST be separable from execution correctness. Mandatory safety checks, completion protocols, checkpoint invariants, and qualification requirements MUST NOT disappear when optional telemetry is disabled.

AOS-CORE-005. Local recording and inspection MUST work without external network access, an account, a hosted service, or an external collector. Remote synchronization and third-party interoperability MUST be optional.

AOS-CORE-006. Normal capture MUST have bounded resource consumption and explicit overload behavior. No finite implementation may claim simultaneous unlimited retention, unlimited producer rate, nonblocking producers, and zero loss.

2.3 Freedom retained by the implementer#

The implementer MAY choose module boundaries, data structures, binary record layouts, compression, batching, ring-buffer designs, native instruction sequences, query indexes, local UI mechanisms, and implementation order. A single-writer design can be conforming; lock-free concurrency is not a prerequisite. A database is not required. A filesystem layout in this document is not a mandated on-disk ABI.

The implementer MUST NOT replace defined semantics with a generic untyped text log, introduce an implicit hosted dependency, or meet a physical qualification requirement using a source-level mock.

3. Architecture and dependency boundaries#

AOS-ARCH-001. The implementation MUST separate five logical responsibilities: semantic descriptions and provenance; acquisition of observations; buffering and persistence; analysis and validation; presentation and export. These responsibilities MAY share a process or executable but MUST have explicit interfaces and failure boundaries.

AOS-ARCH-002. Shared identity, schema, value, context, and relation contracts MUST be target-neutral and model-neutral. Compiler-domain schemas belong with compiler semantics; learning-domain schemas with learning semantics; target measurements with the relevant target or platform provider. Generic contracts MUST NOT depend upward on a concrete learning system or device implementation.

AOS-ARCH-003. Production semantic logic, capture mechanisms, native lowering, codecs, persistence, inspection, and validation MUST be Alpha-owned implementations using the maintained standard library and declared native interfaces. Existing bootstrap/reference code MAY remain an explicitly identified implementation lane. It MUST NOT be misrepresented as qualified Alpha-native execution.

AOS-ARCH-004. Operating-system, kernel-driver, firmware, and hardware interfaces are legitimate declared dependencies. Third-party SDKs, foreign runtimes, databases, or services MUST NOT be compulsory in the core record-and-inspect path. Optional adapters MAY use additional dependencies when their boundary, trust, and deployment consequences are explicit.

AOS-ARCH-005. Browser assets MAY use standard browser capabilities. A browser renderer MUST NOT be the sole authority for parsing, validating, or explaining retained evidence. A terminal or machine-readable interface MUST expose equivalent underlying information.

AOS-ARCH-006. There MUST be one maintained semantic contract for observations and one ownership location for each reusable mechanism. Existing formats MAY coexist during migration, but incompatible parallel logging engines inside individual systems are not an acceptable long-term architecture.

4. Conformance and capability declarations#

4.1 Profiles#

AOS-CONF-001. The baseline Alpha implementation MUST provide Core producer, Core reader, and Local recorder. Compiler provenance, Execution observer, and Learning observer MUST be provided for maintained Alpha paths once those integrations claim support. Device and distributed acquisition MUST be capability-scoped; naming their schemas does not establish acquisition support.

AOS-CONF-002. Every implementation MUST expose a machine-readable capability manifest. It MUST identify implementation/build identity, AOS version, supported profiles, schemas, native encodings, platform/target constraints, capture modes, operational limits, durability guarantees, and qualification evidence.

AOS-CONF-003. Capability status MUST distinguish implemented, source_checked, simulated, native_tested, device_tested, unavailable, unsupported, and disabled where applicable. These are separate facts, not one automatically ordered success ladder. Qualification MUST name its exact target, build, configuration, and test scope.

AOS-CONF-004. Requesting an unsupported capability MUST produce a typed unavailable/rejected result. A policy MAY permit running without it, but that decision and its effect on coverage MUST be recorded. Evidence-required policies MUST reject or remain unqualified when a required capability is absent.

5. Identity, entities, and execution lineage#

5.1 Identity classes#

AOS-ID-001. The model MUST distinguish logical experiment, logical run, execution attempt, producer, producer incarnation/epoch, build, source, schema, policy revision, clock domain, context, activity, resource, artifact, observation site, and validation receipt.

A logical run can contain multiple attempts. A resumed computation starts a new attempt even when the logical run remains the same. A worker or producer restart starts a new producer epoch. An execution attempt MUST NOT be identified only by a configuration hash.

AOS-ID-002. An event identity is the tuple:

(attempt_id, producer_id, producer_epoch, sequence)

sequence is a nonnegative unsigned 64-bit value within that producer epoch. The implementation MUST prevent wraparound from reusing identities. It MAY rotate to a new epoch before exhaustion. A producer that emits concurrently MUST define one publication order or split into independently ordered producer streams.

AOS-ID-003. Instance IDs MUST be opaque, collision-resistant within their declared namespace, and stable after publication. A baseline interchange instance ID is 128 bits rendered as 32 lowercase hexadecimal characters, excluding the all-zero value. The generation algorithm is implementation-defined. Assigned or deterministic namespaced IDs are permitted when uniqueness is justified. Retries of the same operation MUST reuse its idempotency identity rather than minting a misleading new success.

AOS-ID-004. Content identities MUST identify their digest algorithm and exact hashed representation. The baseline artifact digest is SHA-256 [N6]. Short IDs and table indexes are scoped references, not globally meaningful identities. A digest of compressed bytes and a digest of logical uncompressed content MUST be different named attributes when both are used.

AOS-ID-005. Memory addresses, file descriptors, queue slots, PIDs, and device handles MUST NOT serve as durable object identity on their own. Reuse requires generation/lifetime identity. Namespace, tenant, and owner are separate attributes rather than inferred from an ID.

5.2 Entities and versions#

AOS-ID-006. Mutable entities MUST have explicit content/state versions when observations depend on their value. Storage allocation generation, tensor logical identity, tensor view, and tensor content version MUST remain distinguishable. Updating a tensor in place does not create a new allocation, but it does create a new observable content state.

AOS-ID-007. Aliases MUST identify the storage relationship and validity scope. Equivalent content is not necessarily the same entity; the same entity at different times need not have equal content. Deduplication MUST NOT erase these distinctions.

5.3 Run and attempt lifecycle#

AOS-RUN-001. Lifecycle observations MUST distinguish created, starting, running, pausing, paused, stopping, and terminal succeeded, failed, cancelled, or abandoned. Paths that do not support pause MAY reject it. These are reported states, not guarantees of a terminal observation surviving a crash.

AOS-RUN-002. Reader-side unknown, disconnected, stale, and incomplete assessments MUST NOT be rewritten as producer-declared terminal states. An attempt without a terminal record is not automatically successful or failed.

AOS-RUN-003. Resume/fork lineage MUST reference the source run/attempt, checkpoint or other restored state, and restore outcome. Retried attempts MUST remain independently inspectable. Worker failure does not alone determine the terminal state of a distributed run.

6. Values, schemas, and evolution#

6.1 Typed values and availability#

AOS-VAL-001. The core value model MUST represent booleans, UTF-8 text, arbitrary bytes, signed/unsigned machine integers, large integers, decimal values, floating-point bit patterns, references, lists, maps, and explicit null values. Collection lengths and nesting MUST be bounded by declared operational limits.

AOS-VAL-002. Integer counters, sequence IDs, byte counts, and timestamps MUST NOT be silently narrowed or converted through inexact floating-point representations. Floating-point observations MUST support NaN, infinities, signed zero, and exact source-format identification. A finite-only display MAY be derived but MUST retain a link to the original observation.

AOS-VAL-003. Availability MUST be distinct from numeric value. A value-bearing slot MUST distinguish present, not_recorded, unsupported, unavailable, redacted, expired, invalid, and unknown. Optional reasons include permission failure, producer failure, sampling, capacity, and collection failure. Zero MUST NOT mean “not measured.” Explicit data null is a present value, not missingness.

AOS-VAL-004. Units MUST be explicit and machine-readable. Counts, bytes, seconds, ticks, joules, ratios, percentages, and algorithm-specific objective units MUST not be conflated. Scaled or converted values MUST retain source units and conversion provenance. Unitless scores MUST name their definition.

6.2 Schema descriptors#

AOS-SCH-001. Every record kind MUST reference an immutable versioned schema. Its descriptor MUST state owner/namespace, semantic name, version, field types, required fields, units, enum definitions, reference targets, privacy defaults, allowable bounds, and semantic constraints. Reusable descriptors MAY be referenced rather than inlined.

AOS-SCH-002. Published field IDs and meanings MUST NOT be reused. A compatible addition is optional and has explicit absence semantics. Changes in units, aggregation meaning, identity interpretation, or required fields require a new incompatible schema version. Semantic compatibility MUST NOT be inferred solely from identical byte layouts.

AOS-SCH-003. Readers MUST preserve unknown optional fields or provide a declared opaque representation. Unknown required fields or critical extensions MUST prevent a successful validation of affected records. Raw inspection SHOULD remain possible without claiming semantic interpretation.

AOS-SCH-004. Experimental schemas MUST have an explicit experimental namespace/version and SHOULD be promotable through an explicit mapping. A dynamically minted schema is permitted only with a descriptor and resource limits; unrestricted high-cardinality names MUST NOT bypass capture budgets.

AOS-SCH-005. Descriptors and dictionaries required by retained records MUST be retained or explicitly reported missing. Streaming producers SHOULD announce them before first use. Out-of-order delivery MAY create pending references; it MUST NOT create fabricated defaults.

7. Observation envelope and epistemic status#

7.1 Required logical envelope#

AOS-OBS-001. Every observation MUST logically carry or inherit from an unambiguous enclosing segment the following fields. A native encoding MAY omit repeated fields, but standalone interchange MUST materialize them.

Source/build/site/resource associations MUST be available through payload or context when relevant. Collection time and durable-storage time MAY be added separately; they MUST NOT replace source time.

7.2 Epistemic status#

AOS-OBS-002. Origin MUST distinguish direct, reported, derived, simulated, and estimated. Direct means that the named acquisition mechanism observed the specified quantity; it does not mean independently trustworthy. A process reporting its own completion is not a mathematical proof of completion.

AOS-OBS-003. Derived observations MUST identify their input records/artifacts, transformation implementation, parameters, and uncertainty or coverage consequences. Estimates MUST identify a method and assumptions. Simulations MUST identify the simulator and model boundary. Confidence scores MUST NOT be fabricated for purely deterministic calculations or unspecified heuristics.

AOS-OBS-004. Origin, integrity, authenticity, completeness, measurement uncertainty, and validation verdict are independent axes. A checksummed simulated record remains simulated. An authenticated record can be wrong. A partial trace can contain individually valid measurements.

AOS-OBS-005. Observations are immutable after publication. Corrections, supersessions, retractions, and annotations MUST be new records referencing the affected identities and their own authorship. A query MAY expose a corrected view but MUST permit inspection of the original retained facts, subject to deletion/privacy policy.

8. Context, activities, state transitions, and relations#

8.1 Context#

AOS-CTX-001. Context MUST support task/request, component, source site, execution phase, data shard, optimization axis, device/queue, and user-defined domain dimensions without making all fields mandatory. Context snapshots MUST be immutable and versioned if their meaning changes.

AOS-CTX-002. Context propagation MUST follow logical work across asynchronous scheduling and device submission. Thread-local state alone is insufficient when work migrates. Batching and fan-in MUST preserve multiple input contexts through links or a batch membership artifact; a single arbitrary parent MUST NOT erase other contributors.

AOS-CTX-003. Propagated context MUST be bounded and filtered at trust boundaries. It MUST NOT grant authority, imply ownership, or silently expose credentials or arbitrary user data.

8.2 Activities and transitions#

AOS-ACT-001. An activity MUST have an identity, kind, context, and independently recordable start/end or observed interval. It MUST support asynchronous execution, overlapping children, links to multiple causes, retries, cancellations, timeouts, and an unknown/missing endpoint.

AOS-ACT-002. A start without an end MUST remain open or incomplete, not be closed using collector shutdown time as though that were measured execution time. A timeout observation MUST distinguish observer timeout from confirmed cancellation of the underlying work.

AOS-ACT-003. State transitions MUST identify entity, prior state when known, new state, transition cause, and the relevant generation/version. Reader-derived state MUST identify the reducer and coverage assumptions. Illegal or contradictory transitions MUST be surfaced rather than discarded to make the state machine appear valid.

8.3 Typed graph relations#

AOS-REL-001. The model MUST support many-to-many typed relations and n-ary operation occurrences. An occurrence can reference input/output lists or immutable membership artifacts. The graph is a derived index; retaining a mutable graph database in the producer is not required.

AOS-REL-002. Derivation, containment, synchronization, and hypotheses MUST NOT be conflated. An explicit happens-before cycle is inconsistent evidence; a waits-for cycle can be meaningful diagnostic data. Readers MUST retain and explain such distinctions.

AOS-REL-003. Missing endpoints MUST have unresolved-reference outcomes. A query MUST distinguish pending arrival, dropped data, expired data, denied access, and unknown availability without leaking unauthorized existence information.

9. Time, order, and clock correlation#

AOS-TIME-001. Every timestamp MUST identify its clock domain and epoch. A clock descriptor MUST state source/provider, raw counter width, unit or tick-rate model, monotonicity claims, wrap/reset behavior, resolution when known, and any suspend/frequency-change semantics relevant to interpretation. Unknown properties MUST remain unknown.

AOS-TIME-002. CPU elapsed intervals MUST use a suitable monotonic source when supported. Wall-clock time is for civil-time association, not an interchangeable substitute for monotonic elapsed time. Native platform providers MUST document actual clock semantics. Imported timestamps MUST retain their original source rather than being relabelled.

AOS-TIME-003. Device execution times MUST come from a qualified device observation mechanism when labelled device execution times. Host enqueue, doorbell, poll, completion-detection, and host-wait times are separately named quantities. A host wait interval MUST NOT be exported as an exact device or kernel duration.

AOS-TIME-004. Cross-domain conversion MUST reference a clock-correlation record containing source/destination domains, calibration observations, conversion method, validity interval, and uncertainty. The implementation MAY use piecewise affine mappings or another justified method. Unknown uncertainty MUST NOT become zero uncertainty.

AOS-TIME-005. Clock reset, wrapping, invalid readings, changed rate, and non-monotonic observations MUST be detected where the provider can detect them and reflected in domain epochs or invalidation records. Uncorrelated devices or hosts MUST remain on separate time axes rather than being overlaid as exactly synchronized.

AOS-TIME-006. Per-producer sequence establishes recording order. It does not automatically establish execution order between independent activities. Explicit synchronization, message correspondence, or domain semantics is required to assert happens-before. A deterministic merged presentation order MAY break ties by identity but MUST be labelled a presentation order.

AOS-TIME-007. Duration and critical-path calculations MUST preserve measurement scope and overlap semantics. Inclusive child durations MUST NOT be summed as exclusive parent time when children overlap. Missing endpoints, uncorrelated clocks, queueing, and partial sampling MUST be reflected in bounds or an unavailable result rather than false precision.

AOS-TIME-008. Logical progress axes, Lamport-style ordering, or algorithmic steps MAY coexist with physical time. A logical clock MUST NOT be converted into physical duration without an explicit model. Clock collection failure MUST NOT prevent sequence-based inspection of otherwise valid data.

10. Coverage, completeness, and data loss#

10.1 Coverage is a scoped statement#

AOS-COV-001. A completeness claim MUST name its attempt(s), producer membership epochs, observation kinds/sites, policy revisions, sequence/time windows, and whether artifacts and descriptors are included. “Complete” MUST mean complete for that declared selection, not that every physical event was observed.

AOS-COV-002. Reader results MUST distinguish policy exclusion, statistical sampling, overload loss, transport delay, storage corruption, producer disappearance, retention expiry, redaction, denied access, and unknown coverage. Several conditions MAY apply simultaneously.

AOS-COV-003. Expected producer membership MUST be explicitly declared when proving aggregate completeness. Dynamic membership changes require versioned membership observations. A missing worker MUST NOT disappear from the completeness calculation merely because it stopped sending records.

10.2 Sequence and loss accounting#

AOS-COV-004. A producer SHOULD assign sequence numbers after policy selection but before bounded publication. Capacity loss after assignment MUST retain or later report the lost identity range when known. Intentionally excluded candidate events need not consume event sequence numbers; their selection rule and available aggregate counts MUST remain distinguishable from overload loss.

AOS-COV-005. Loss accounting MUST state stream, range/window, cause, count semantics, and whether a count is exact, a lower bound, or unknown. A crash can leave an unknown tail; implementations MUST NOT invent an exact count when no surviving counter establishes it.

AOS-COV-006. Shared sequence counters MUST NOT become an unbounded global bottleneck. Producers MAY reserve sequence ranges or partition streams, provided unused reservations and publication order have explicit semantics and are not mistaken for lost physical observations.

AOS-COV-007. A persistent coverage watermark MUST distinguish records present, ranges accounted for as loss, and unaccounted ranges. A watermark that accounts for loss is not a claim that those records were retained. Artifact readiness, descriptor readiness, and event durability have separate watermarks or status fields.

10.3 Completion#

AOS-COV-008. A cleanly closed producer MUST emit or publish its terminal sequence boundary and coverage summary when possible. A run-wide complete result requires the declared membership and policy conditions to hold. Collector receipt of a run-end message alone is insufficient.

AOS-COV-009. Downsampling, compaction, import, export, and aggregation MUST propagate or conservatively weaken coverage. A derived view MUST NOT become more complete than its inputs merely because it contains fewer rows.

11. Capture policy, budgets, and admission#

AOS-POL-001. Capture policy MUST be explicit, immutable by revision, inspectable, and attributable to every selected observation. A policy MUST define enabled domains/sites, record severity/class selection, sampling, aggregation, artifact permissions, resource budgets, retention intent, and overload action.

AOS-POL-002. Capture profiles MUST include an equivalent of off, basic, profile, and focused. Names are not prescribed. off disables optional acquisition, not required execution protocols or independent evidence obligations. Basic capture MUST avoid arbitrary raw data capture by default.

AOS-POL-003. Evidence policy, capture policy, and security policy MUST be distinct. A user-requested capture change cannot override privacy or required-evidence rules. Conflicts MUST produce a typed rejection or an explicitly permitted degraded result.

AOS-POL-004. Budgets MUST cover host/device memory, emitted bytes/rate, live series cardinality, descriptor/dictionary growth, artifact bytes, storage consumption, query work, and collection overhead where controllable. Limits MUST have units and scope. Finite defaults MUST be provided.

AOS-POL-005. Sampling descriptors MUST identify selection method, unit of selection, effective probability when meaningful, deterministic seed/key policy when applicable, and the window over which the policy holds. Nonrandom selection MUST NOT be presented as an unbiased sample. Policy RNG state MUST be independent of model RNG state.

AOS-POL-006. Policy changes MUST identify issuer, authorization, revision, requested/effective boundary, and result. A device MAY adopt changes only at supported boundaries. The system MUST NOT claim instantaneous activation if buffered or already submitted work retains an older policy.

AOS-POL-007. Focused and triggered capture MUST declare scope, pre-trigger retention capacity, post-trigger window, escalation limits, cooldown, and exhaustion action. Pre-trigger data MUST NOT be promised unless it was retained. A trigger cannot retrospectively create unrecorded device detail.

AOS-POL-008. Required-evidence work MUST reserve sufficient bounded recording capacity or have an explicit durable-admission protocol before proceeding past the relevant irreversible boundary. Exhaustion MUST stop or reject further covered work at a safe boundary, or make the attempted qualification fail. It MUST NOT disable cleanup, safety checks, or necessary device completion.

AOS-POL-009. Essential diagnostics SHOULD bypass ordinary statistical sampling but remain subject to finite capacity and failure semantics. “Never sample” does not mean “guaranteed to survive any crash.” Repeated diagnostics MAY be coalesced with exact/lower-bound counts and first/last occurrence information.

12. Producer API and hot-path behavior#

AOS-API-001. The producer interface MUST offer typed operations equivalent to descriptor registration, context creation/propagation, event emission, activity observation, metric recording, relation recording, artifact association, capture status, flushing, and closing. Actual names and surface syntax are implementation choices.

AOS-API-002. Observation operations MUST fit Alpha's explicit effect/resource model. They MUST NOT invent a file, host, device, or network capability. Pure code MUST NOT acquire hidden I/O effects. A computation needing guaranteed recording MUST have an explicit failure/admission contract.

AOS-API-003. Emission MUST distinguish outcomes equivalent to accepted into a buffer, excluded by policy, dropped by capacity, and unavailable/failed. Acceptance into memory MUST NOT be reported as durable storage. Producers MAY aggregate per-event outcomes rather than branching on every best-effort emission, provided the aggregate status remains accessible.

AOS-API-004. The fast path MUST have bounded work and MUST NOT synchronously perform network I/O, filesystem synchronization, arbitrary formatting, whole-record cryptographic hashing, or unbounded allocation. Specialized fixed-size native writes are permitted. Descriptor registration and cold-path encoding can have different cost classes.

AOS-API-005. Payload expressions that exist solely for disabled optional observation MUST NOT execute. An API MUST NOT eagerly compute a tensor reduction or format a string and only then test whether capture is enabled. The compiler or API must provide lazy/staged selection with documented semantics.

AOS-API-006. Instrumentation MUST NOT duplicate linear resources, retain an invalid borrow, or extend a storage lifetime invisibly. An asynchronous snapshot must own a valid copy or explicitly retain access to a versioned resource until capture completes.

AOS-API-007. Producer methods MUST define thread/task/signal/interrupt safety. A method not safe in a crash handler MUST not be used there. Emergency paths MUST avoid depending on the allocator, locks, or file state whose failure they are reporting.

AOS-API-008. Registration and dynamic contexts MUST be bounded. Hot loops SHOULD use cached descriptors and local IDs. A failed registration MUST return a defined status rather than silently generating an incompatible anonymous schema.

13. Compiler integration and static provenance#

13.1 Build-associated manifest#

AOS-COMP-001. A compiler-provenance implementation MUST emit or reference an immutable manifest linking source closure, compiler identity/configuration, language edition, dependency identities, target/provider identities, and resulting build/artifact identity. Dirty or generated inputs MUST be represented by actual content identities, not solely a repository commit label.

AOS-COMP-002. The manifest MUST support definitions and source spans, representation versions, transformation occurrences, input/output memberships, erased/retained objects, chosen/rejected alternatives where captured, schedules, resource plans, executable regions, launch sites, and observation-site descriptors. Inapplicable entries need not be fabricated.

AOS-COMP-003. Source association MUST identify source content and span encoding. Generated code MUST retain origin mappings when available. Inlined, fused, split, duplicated, and eliminated operations MUST support many-to-many provenance rather than forcing one output to one source line.

13.2 Compiler phases and decisions#

AOS-COMP-004. Compiler runtime observation MUST support time and counters for module resolution, parsing, elaboration, checking, normalization, proof processing, erasure, transformation, planning, lowering, encoding, linking, and artifact publication when these phases are present. Recursive/repeated phase instances MUST have distinct identities.

AOS-COMP-005. Incremental compilation MUST distinguish cache lookup, hit/miss, validation, dependency invalidation, restoration, and recomputation. A cache-hit record MUST reference the reused artifact and its validation basis; it MUST NOT imply that skipped work was freshly executed.

AOS-COMP-006. Search/autotuning decisions MUST identify candidate set or retained candidate artifact, objective, measured versus estimated cost, constraints, selection result, and applicable target. Uncaptured candidates MAY remain unavailable. A heuristic selection MUST NOT be presented as globally optimal.

13.3 Instrumentation lowering#

AOS-COMP-007. Observation sites MUST survive representation changes through explicit mappings. Runtime events MUST carry live runtime operands when claiming live values. Compile-time construction of bytes describing a success is not a runtime observation of success.

AOS-COMP-008. Instrumentation policy MUST participate in build identity, cache invalidation, layout, resource accounting, and optimization decisions whenever it changes generated code or resource use. A normal and an instrumented binary MUST remain separately identifiable even if most code is shared.

AOS-COMP-009. Disabled optional observation SHOULD erase to the same relevant computational code and resource behavior as an uninstrumented build. Any residual branch, descriptor, call, allocation, barrier, or layout change MUST be disclosed and measured. Required safety/evidence effects are not part of this erasure promise.

AOS-COMP-010. Unsupported native lowering for an observation MUST fail explicitly or produce an allowed unavailable capability outcome. It MUST NOT silently execute the learning operation, tensor reduction, or measurement through a foreign host framework.

14. Runtime, scheduler, and resource observation#

AOS-EXEC-001. Runtime observation MUST accommodate graph evaluation, scalar native code, cooperative/persistent device execution, task queues, pipelines, continuations, and other execution models through common work-instance and resource identities. It MUST NOT require a traditional per-operator kernel launch model.

AOS-EXEC-002. Scheduling records MUST support creation, readiness, enqueue, dequeue, dispatch, suspension, wait, wake, steal/migration, cancellation, retry, and completion when applicable. Enqueueing is not starting; dispatching is not completing. Queue depth and wait reasons MUST state whether directly observed or reconstructed.

AOS-EXEC-003. Resource observation MUST cover allocation, reservation, mapping, binding, transfer, borrow/ownership change, release, reuse, and failure. Logical requested bytes, physical committed bytes, resident bytes, reserved address space, and allocator overhead MUST remain distinct quantities.

AOS-EXEC-004. Memory/resource summaries MUST declare whether derived from lifetime events, allocator counters, operating-system samples, or estimates. Missing alloc/free events MUST prevent an unjustified claim of an exact leak or exact live-set size. Peak observations MUST identify their sampling limitations.

AOS-EXEC-005. Synchronization observation MUST distinguish completion signals, polling, barriers, fences, locks, dependency waits, and timeouts. A sampled poll result MUST not be promoted to the exact time the device completed. Timeout and cancellation MUST preserve the possibility that underlying work is still active.

AOS-EXEC-006. Native operations and failures MUST preserve relevant operation identity, target/provider, request/result status, error domain, retry, and cleanup state. Sensitive arguments MAY be redacted. Platform error numbers MUST be tagged with their platform/ABI meaning rather than assumed globally portable.

AOS-EXEC-007. Runtime snapshots MUST declare consistency semantics: atomic, version-consistent, quiescent, per-field sampled, or approximate. A collection of separately sampled counters MUST NOT be presented as one atomic system state.

14.1 Sampled profiles, symbols, and executable lifetimes#

AOS-PROF-001. The model MUST accommodate sampled instruction pointers, call stacks, allocation stacks, execution counters, and hardware/system profiles without treating a sample as an exact activity boundary. Acquisition is provider-scoped; support for displaying a profile does not establish support for collecting it on every target.

AOS-PROF-002. A profile sample MUST identify producer/target, acquisition mechanism, sample time/clock, configured rate or trigger, observed weight/count, execution context when known, and missed/invalid sample accounting. Biased sampling, multiplexed counters, and interrupted acquisition MUST be disclosed. Sample proportions MUST NOT be presented as exact elapsed-time partitions without a justified model.

AOS-PROF-003. Address-to-code association MUST identify executable build/region, address-space identity, load/unload generation, relocation/base mapping, and validity interval. JIT-generated, dynamically replaced, or reloaded code MUST receive appropriate generation identity. Reused addresses MUST not symbolize against the wrong image.

AOS-PROF-004. Symbolization MUST preserve original address observations and identify symbol/source-map inputs. Missing, stale, or mismatched symbols MUST remain unresolved. Inlined or fused provenance MAY produce multiple logical source associations; a renderer MUST not collapse those into a false single physical stack frame.

AOS-PROF-005. Stack capture MUST distinguish physical frames, reconstructed inline frames, asynchronous continuation links, and inferred frames. Partial/unwind-failed stacks MUST remain marked partial. Capturing a stack MUST not imply arbitrary stack-memory capture or permission to retain secrets found in that memory.

AOS-PROF-006. Profile aggregation MUST identify inclusive/exclusive semantics, sample weight, population, grouping, symbolization version, and coverage. Flame graphs and other presentations MUST expose the underlying measurement definition rather than presenting all sample counts as CPU seconds.

AOS-PROF-007. Instrumented checks such as bounds, ownership, race, or memory-lifetime probes MUST distinguish detection coverage from proof of absence. A clean sampled or instrumented run MUST not be reported as proof that no race, leak, or invalid access is possible.

15. Accelerator and device observation#

15.1 Target-neutral contract and provider-specific acquisition#

AOS-DEV-001. Each device provider MUST declare supported observation mechanisms, raw data semantics, timestamp support, counter support, memory visibility requirements, limitations, and exact qualification target. A generic schema's existence MUST NOT imply every target supports it.

AOS-DEV-002. Device observation MUST support both submission-level and inside-execution observations where implemented. Persistent programs MUST be able to identify internal work phases or epochs without pretending each phase is a separate host launch.

AOS-DEV-003. Submission identity MUST associate executable region/build, parameter/layout version, queue/channel, work/context, and synchronization dependencies. Host submission, device acceptance when observable, device progress, device completion, host completion detection, and numerical validation MUST be distinguishable.

15.2 Capture memory and publication#

AOS-DEV-004. Device capture storage MUST be preplanned or explicitly admitted, bounded, disjoint from application-owned writable regions unless a safe shared scheme is proven, and included in target resource accounting. Capture MUST NOT write out of bounds when the stream overflows.

AOS-DEV-005. Multi-thread/block/wave writers MUST have an explicit ownership or reservation protocol. Per-wave/block buffering, static slots, batched reservations, and aggregation are permitted. A globally contended counter for every lane is not required and SHOULD be avoided when a bounded less-contended scheme exists.

AOS-DEV-006. The provider MUST specify record reservation, payload initialization, publication ordering, visibility scope, consumer acquisition, reuse, and reset. An atomic index increment alone MUST NOT be treated as proof that payload bytes are visible to another device or the host.

AOS-DEV-007. Host readers MUST NOT consume partially written device records or reuse device buffers before ownership returns. Cross-device/system-scope fences, completion tokens, copies, cache-management operations, and host coherence MUST be qualified for the actual path. Unsupported concurrent visibility MUST lead to boundary-based draining, not speculative polling of incoherent memory.

AOS-DEV-008. Draining SHOULD overlap unrelated computation where supported, but MUST preserve tensor/capture-buffer lifetimes and data dependencies. Logging MUST NOT introduce an implicit whole-device synchronization on every observation. Necessary telemetry-specific synchronization MUST be explicit and measured.

15.3 Cost and failure#

AOS-DEV-009. Inside-execution instrumentation MUST account for extra instructions, registers, local/shared memory, barriers, occupancy/resource changes, code size, data movement, and perturbation of scheduling. An instrumentation build MUST have a distinct measurement profile and identity.

AOS-DEV-010. Device overload MUST terminate the attempted record safely, aggregate loss, or follow another bounded policy. A device MUST NOT spin indefinitely waiting for a host recorder to drain optional telemetry. Required device evidence needs admission/backpressure at a safe protocol boundary rather than an unbounded in-execution wait.

AOS-DEV-011. Device reset/loss MUST invalidate affected clock domains, active submission/completion assumptions, resource handles, and unread buffer contents as appropriate. Host-retained records remain inspectable. A device fault does not guarantee recoverability of its final device-local observations.

AOS-DEV-012. Device counters MUST declare measurement scope, multiplexing, estimated versus measured quantities, privilege requirements, and contamination by other work when relevant. Device-wide power or utilization MUST NOT be attributed exactly to one run without a valid attribution model.

16. Numerical and tensor observation#

AOS-NUM-001. Tensor observations MUST identify logical tensor, content version, storage/view identity where applicable, shape, axis meaning when known, dtype, layout/strides, device, and the operation/context responsible for the observed state.

AOS-NUM-002. Supported summaries SHOULD include finite/nonfinite counts, min/max, mean/variance, norms, zero/sparsity counts, clipping/saturation counts, and histograms. A provider implements only the summaries it can acquire correctly; absent summaries MUST be unavailable, not fabricated.

AOS-NUM-003. Each summary MUST state its exact input population, sampling rule, accumulation precision, reduction algorithm/version where materially relevant, and treatment of NaN, infinities, masks, empty tensors, and overflow. Comparing summaries with different definitions MUST surface the incompatibility.

AOS-NUM-004. GPU summaries MUST be computed through an admitted device path, or through an explicitly chosen and identified host-analysis path after data transfer. The system MUST NOT silently copy a tensor to the CPU solely because the device summary implementation is missing.

AOS-NUM-005. Capturing a summary or raw slice MUST name the logical time/version it observes. An asynchronous collector MUST NOT read a mutable buffer after it has changed and label the result as the earlier version. Valid strategies include retained ownership, copy-on-capture, a consistent snapshot, or an explicitly approximate sample.

AOS-NUM-006. Numerical anomaly detectors MUST separate detection, diagnostic capture, and corrective action. A finite check that is part of algorithmic safety MUST not be erased as optional logging. Automatic loss-scale changes, skipped updates, clipping, rollback, or early stopping MUST be recorded as actual control decisions with their triggering information.

AOS-NUM-007. Raw values, activations, gradients, parameters, token sequences, and predictions are opt-in captures with classification, size, retention, and authorization controls. Raw tensor dumps SHOULD be artifacts rather than large event payloads.

AOS-NUM-008. A sampled tensor fingerprint MUST declare its sampling and collision limitations. A fingerprint or finite-value check MUST NOT be represented as proof of tensor equality or overall numerical correctness.

17. Learning, experiments, and evaluation#

17.1 Generic experiment semantics#

AOS-LEARN-001. Experiment tracking MUST support arbitrary learning systems, including gradient-based, recurrent/stateful, local-update, search-based, evolutionary, diffusion, retrieval, symbolic, and hybrid systems. Domain-specific schemas MAY extend the core; no backward-pass or optimizer-step field is universally mandatory.

AOS-LEARN-002. Run metadata MUST support system/component identity, resolved configuration, dataset/input identities, initialization, seed/RNG policy, numerical policy, objective definitions, target facts, environment facts, and artifact lineage. Unknown or unrecorded inputs MUST be explicit.

AOS-LEARN-003. Progress MUST use named axes, including optimization step, microstep, accepted update, tokens, samples, epoch, trial, generation, iteration, or domain-specific counters. Axes MUST distinguish reset on resume, continuation, skipped work, and speculative/retried work. Event sequence is not an optimization step.

17.2 Metrics#

AOS-MET-001. A metric descriptor MUST identify name, schema/version, scalar/distribution kind, units, dimensions, temporal aggregation, population aggregation, axis binding, and permitted label cardinality. Same-name metrics with different semantics MUST not be merged automatically.

AOS-MET-002. Counters MUST identify cumulative versus delta semantics, reset epoch, window boundaries, and monotonicity where promised. Gauges MUST identify observation time and freshness. A scrape/collection time MUST NOT replace an older source sample time without preserving both.

AOS-MET-003. Distributions MUST include bucket/sketch definition, population count, weight semantics, and merge compatibility. Explicit histogram intervals MUST define endpoint inclusion. A histogram with NaN/overflow populations MUST account for them separately when they are excluded from numeric buckets.

AOS-MET-004. Aggregation MUST NOT average percentiles, unweighted per-worker means with unequal sample counts, or incompatible sketches as though these were valid global reductions. Loss/accuracy summaries MUST retain the appropriate sums, denominators, weights, masks, and population definitions needed for the declared aggregation.

AOS-MET-005. High-frequency counters SHOULD be accumulated near the producer and exported periodically. Metric labels MUST be bounded; arbitrary tensor IDs, event IDs, prompts, and raw paths SHOULD be references or event fields instead. Cardinality admission and overflow MUST be observable.

AOS-MET-006. Out-of-order samples, duplicates, corrections, counter resets, partial windows, and stale series MUST have deterministic semantics. A missing observation MUST NOT be rendered as a measured zero. Interpolation/smoothing MUST be a labelled presentation or analytic transform.

17.3 Learning and evaluation state#

AOS-LEARN-004. Learning records MUST support objective components, update acceptance/skipping, optimizer or learner state version, schedules, accumulation, clipping, precision/loss-scale policy, and state transitions when applicable. Metric reads MUST be associated with the parameter/state version evaluated.

AOS-LEARN-005. Dataset lineage MUST represent dataset/version, preprocessing/tokenization/configuration, split, shard, cursor/order, augmentation/sampling state, and replay availability where relevant. Recording a dataset name alone MUST NOT establish identical data across runs.

AOS-LEARN-006. Evaluation records MUST identify evaluated state/checkpoint, dataset/split, evaluator/rubric/version, aggregation, sample count, failures/exclusions, and reproducibility information. Asynchronous evaluation MUST retain the older model identity rather than being attached to whatever state is current when results arrive.

AOS-LEARN-007. Comparisons MUST state axis alignment, compatible metric definitions, included attempts, excluded/warm-up windows, target/environment differences, sample populations, and uncertainty. A benchmark winner or regression verdict MUST reference its decision rule rather than an unexplained ranking.

18. Distributed, service, and agent execution#

AOS-DIST-001. Distributed records MUST distinguish logical rank/role, process identity, device identity, membership epoch, and physical host. Elastic reassignment and rank reuse MUST NOT merge unrelated producer lifetimes.

AOS-DIST-002. Messages, transfers, and collectives MUST have identities sufficient to associate send/enqueue, receipt, processing, retry, and completion. Batched and fan-in work MUST preserve constituent relationships. Receipt at a transport does not imply application processing.

AOS-DIST-003. Collective observations MUST identify operation instance, communicator/membership epoch, participating set or set descriptor, relevant shard/shape/dtype, and completion semantics. Per-rank times MUST NOT be summed into a global elapsed time without an explicit interpretation.

AOS-DIST-004. Network partitions and disconnected workers MUST be supported without requiring global total-order consensus for optional capture. Each producer MUST retain local ordering and coverage information. Partial distributed runs MUST remain useful to inspect.

AOS-DIST-005. Retries, duplicate delivery, speculative execution, cancellation, and abandoned work MUST remain distinct. “Exactly once” MUST refer to a defined operation, storage boundary, and failure model; deduplicated delivery of an event does not establish exactly-once execution of its computation.

AOS-SVC-001. Service/request observation MUST support ingress, admission, queueing, execution, streaming output, completion, timeout, cancellation, and errors, with redacted request/response metadata. Raw request bodies MUST not be required for useful tracing.

AOS-SVC-002. An HTTP interoperability adapter MAY implement W3C Trace Context [N5]. External trace identifiers MUST map explicitly to Alpha context and MUST NOT replace run, artifact, or producer identity. Remote context and sampling requests MUST remain untrusted, bounded inputs, not authorization.

AOS-AGENT-001. Agent/orchestrator schemas MUST support session/task, model invocation, tool invocation, delegated work, approval, artifact mutation, external effect, retry, and result assessment. Requests, plans, and model-generated explanations MUST remain distinct from executed effects and validated outcomes.

AOS-AGENT-002. Agent-produced annotations or incident hypotheses MUST identify their author/model/tool context and supporting observations. They MUST NOT overwrite raw records, invent missing causal edges, or become a passing validation receipt solely because an agent asserted them.

19. Diagnostics, failures, and incident capture#

AOS-DIAG-001. Diagnostics MUST have stable namespaced codes, severity, structured context, affected operation/entity, and human-readable explanation or a renderable message descriptor. Source span, error domain/code, retryability, and remediation MAY be attached. Machine clients MUST NOT need to parse prose to discover the primary failure.

AOS-DIAG-002. Severity, execution outcome, evidence validity, and data integrity MUST be independent. A warning does not necessarily invalidate a run; a successful process exit does not establish evidence completeness; an invalid trace does not necessarily establish incorrect model output.

AOS-DIAG-003. Failure records MUST distinguish cause observed at a boundary from an inferred root cause. Error chains MUST preserve independent contributors and related failures. Cleanup failures MUST NOT overwrite the original failure or disappear behind it.

AOS-DIAG-004. Incident capture SHOULD combine a bounded preceding window, targeted subsequent observations, manifest and policy identities, known resource state, and relevant artifact references. Trigger conditions and capture losses MUST be part of the incident record.

AOS-DIAG-005. Process crash, forced termination, device reset, host loss, storage failure, and abrupt power loss MUST have separate supported recovery assumptions. A best-effort crash marker is not a guarantee of last-event survival. A crash handler MUST NOT attempt unsafe allocation, arbitrary formatting, lock acquisition, or device queries unless explicitly qualified for that context.

AOS-DIAG-006. Emergency reporting MUST have an independent bounded path or status area. Recorder errors MUST NOT recursively generate unbounded recorder errors. Repeated failures SHOULD be coalesced while retaining the first meaningful failure and available counts.

20. Recording channels and buffering#

20.1 Logical channels#

AOS-CHAN-001. The architecture MUST distinguish at least three policy classes, even if they share a physical container:

AOS-CHAN-002. Essential descriptors, capture status, and failure summaries MUST receive a protected budget or equivalent bounded treatment. Priority alone MUST NOT be described as guaranteed persistence. When even the protected path fails, surviving state MUST identify the resulting uncertainty where possible.

20.2 Buffer protocol#

AOS-BUF-001. Every buffer MUST have an explicit owner/writer model, bounds, maximum record/frame size, publication rule, reuse rule, lifecycle, and overload action. Possible implementations include single-producer batches, SPSC rings, multiple streams, or another qualified protocol. Architecture does not mandate lock-free algorithms.

AOS-BUF-002. Readers MUST never observe uninitialized payload as a committed record. Publication/acquisition ordering MUST match the actual host/device memory model. Source-level atomic notation alone does not establish native ordering correctness.

AOS-BUF-003. Overload actions MUST be one or more of drop-new, bounded overwrite-old, coalesce/aggregate, reduce fidelity, spill within a bounded budget, bounded safe-point blocking, or reject further work. The effective action MUST be recorded or reconstructible from a surviving status area.

AOS-BUF-004. Overwrite-old flight recorders MUST not overwrite records still owned by a consumer or silently invalidate descriptors needed by the retained window. Wraparound, generation, and snapshot consistency MUST be explicit. A consumer MUST be able to detect that it missed a window.

AOS-BUF-005. Any blocking behavior MUST state its maximum wait/deadline, cancellation response, allowed call contexts, and effect on execution. Device critical sections and failure handlers MUST NOT block on an optional collector.

AOS-BUF-006. Buffers MUST be released only after all writers and asynchronous readers/copies relinquish access. Shutdown MUST have bounded drain behavior and distinguish cleanly drained from timed out or abandoned. A timeout MUST not lead to use-after-free by a late writer.

AOS-BUF-007. One producer MUST NOT monopolize all capacity without an explicit policy permitting it. Independent producers, diagnostics, and required-evidence traffic SHOULD have fair or reserved budgets. Consumer stall MUST not cause unbounded producer heap growth.

AOS-BUF-008. Bounded algorithmic work and a configured timeout MUST NOT be advertised as a hard wall-clock guarantee on an execution platform that cannot enforce it. Potentially unbounded operating-system or driver waits MUST be isolated from optional producer progress or explicitly declared outside the bounded-progress guarantee. Abandoning a timed-out operation MUST preserve the ownership of any memory or resource it may still access.

21. Persistent journal and durability#

21.1 Durability states and failure model#

AOS-PERSIST-001. Persistent recording MUST distinguish selected, buffered, written, durable, and replicated states. These are separately observable acknowledgements, not synonyms. A storage profile MUST identify which failures its durable acknowledgement is intended to survive and the filesystem/storage assumptions involved.

AOS-PERSIST-002. A local durable acknowledgement MUST only advance after the storage operations required by that profile succeed. For Linux implementations, short writes and the separation between file synchronization and directory-entry synchronization must be handled according to the actual OS interface [N3, N4]. Memory ordering, file write completion, and storage durability are separate protocols.

AOS-PERSIST-003. Durability MUST be represented per producer/segment/range, not as a fabricated global sequence. A synchronized chunk can account for explicit lost ranges while remaining incomplete as an observation history. Watermark records MUST not claim their own unsynchronized bytes are durable. Restart recovery MUST conservatively reconstruct committed boundaries.

21.2 Append and sealing#

AOS-PERSIST-004. The journal MUST use an append or bounded-segment publication protocol with explicit framing and integrity. Appending one record MUST NOT require reading and rewriting the entire run history. Existing immutable data MUST not be modified silently.

AOS-PERSIST-005. A writer MUST handle partial successful writes by tracking progress through the remaining bytes. It MUST classify retryable failures by operation and MUST not duplicate an already written prefix. Zero-progress, interrupted, uncertain, and terminal failures MUST have bounded defined handling. Close, rename, sync, and write MUST not be assumed to share the same retry semantics.

AOS-PERSIST-006. Segment metadata MUST identify encoding/version, attempt, producer/epoch, sequence coverage, clock/schema/policy references, resource limits, and integrity method. Sealing MUST identify the committed extent and integrity of the sealed representation. Compression MUST be lossless for a segment claimed to preserve raw events.

AOS-PERSIST-007. Shared-file multiwriter use is permitted only with a qualified framing/serialization contract. Independent per-producer files are permitted and SHOULD be preferred over an unspecified assumption that arbitrary appends cannot interleave.

21.3 Recovery#

AOS-REC-001. Recovery MUST distinguish a valid prefix with an incomplete tail, corrupt content, missing segment, unsupported encoding, missing descriptors/artifacts, and a fully sealed segment. It MUST never fabricate a terminal run outcome.

AOS-REC-002. A malformed length or checksum failure MUST not cause an unbounded scan/allocation. Resynchronization beyond corruption is permitted only through a defined framing recovery mechanism and MUST report the skipped region. Salvaged data MUST not be represented as one uninterrupted complete stream.

AOS-REC-003. Automatic recovery MUST preserve source bytes or perform a versioned repair with recorded provenance. Silent destructive truncation of the only retained evidence is prohibited. Indexes MAY be discarded and rebuilt because they are derived data.

AOS-REC-004. Disk-full, quota, permission, read-only filesystem, disappearing mount, sync failure, and unavailable storage MUST trigger the declared overload/evidence policy. A telemetry filesystem failure MUST not deadlock required device cleanup or application shutdown.

AOS-REC-005. Buffer acceptance followed by process/host loss MUST remain possible within a declared loss window. Stronger guarantees require stronger acknowledged protocols; merely calling a channel durable does not supply them.

22. Artifacts, checkpoints, and reproducibility#

22.1 Artifact identity and publication#

AOS-ART-001. An artifact descriptor MUST state content identity, media/schema kind, logical size, creation/capture context, classification, ownership, availability, and provenance. Physical location MUST be separate from content identity and MAY change without changing the logical artifact.

AOS-ART-002. Artifact publication MUST distinguish requested, capturing/writing, content complete, integrity verified, and committed/published. A journal record MUST NOT claim a durably published artifact before the required artifact-publication protocol succeeds. Early intent records MUST be labelled intent.

AOS-ART-003. Publication SHOULD use immutable content and an explicit visibility/commit boundary. Partially written content MUST not be exposed as a valid checkpoint. Chunked artifacts MUST identify ordered chunks, digests, lengths, and assembly semantics. A consumer MUST validate the descriptor as well as chunk contents.

AOS-ART-004. Content addressing MUST NOT bypass owner/access controls or leak cross-tenant equality by default. Deduplication is an implementation detail, not permission to expose another owner's artifact.

22.2 Checkpoints and consistent state#

AOS-CKPT-001. Checkpoint metadata MUST identify the state being restored, algorithm/system/build compatibility, parameter and learner state, progress axes, relevant RNG state, input cursor/order, and distributed membership/shard state where necessary. A partial checkpoint MUST state its omissions.

AOS-CKPT-002. A checkpoint MUST identify the consistency boundary it captures. For distributed state, this MAY be a vector of participant boundaries or another defined consistent-cut protocol. Reading each worker at an arbitrary independent time MUST not be represented as a consistent checkpoint without justification.

AOS-CKPT-003. Resume MUST validate the relevant checkpoint and compatibility contract, record the restore outcome, and start an identifiable new attempt. Checkpoint publication, checkpoint restoration, and successful continuation are separate observations.

22.3 Replay levels#

AOS-REPLAY-001. The system MUST distinguish these levels of replay:

AOS-REPLAY-002. Support for one level MUST NOT imply support for a stronger level. Event history alone MUST NOT claim recovery of unrecorded tensor contents, external responses, scheduler decisions, or RNG state.

AOS-REPLAY-003. A reproducibility assessment MUST identify required and available inputs, environment/target/build constraints, nondeterministic operations, external dependencies, comparison criterion, and evidence. Seeds alone are insufficient unless the algorithm's full state and consumption order are established.

AOS-REPLAY-004. Replay with external side effects MUST default to inspection/simulation or require explicit authorization for re-execution. Replaying an agent trace MUST NOT resend emails, mutate repositories, or repeat payments simply because the original trace contains those operations.

23. Native encodings and interchange#

23.1 Native format freedom#

AOS-FMT-001. Internal and native persistent encodings are implementation choices. The implementation SHOULD evolve the maintained Alpha recording format rather than create a competing format family. Existing magic/version identifiers MUST not be reused with incompatible meanings.

AOS-FMT-002. Every native encoding MUST have a versioned public format contract specifying byte order, framing, alignment/padding, integer and floating-point representation, dictionary scope, lengths/limits, integrity, optional/critical extensions, and recovery behavior. Host ABI-dependent struct dumps do not satisfy this requirement.

AOS-FMT-003. Native capture layouts MAY differ from persistent encodings. Expensive hashing, compression, string interning, or metadata enrichment SHOULD occur outside hot acquisition paths. Such transformations MUST preserve identities, original measurement semantics, and coverage.

AOS-FMT-004. An encoded event MUST have a bounded independently identifiable extent. Unknown optional records MUST be skippable safely. Unknown critical schemas MAY be retained opaquely but MUST prevent affected successful validation.

AOS-FMT-005. Readers MUST reject or bound integer overflow, excessive nesting, decompression expansion, invalid references, oversized frames, unsupported codecs, and malformed checksums. Parsing a trace MUST NOT execute code supplied by that trace.

23.2 Interoperability boundary#

AOS-FMT-006. Every Core reader MUST implement AOS-JSON/1. Every supported native format MUST be exportable to it without losing known core semantics. Unknown payloads MUST either be preserved opaquely with their encoding/schema identity or explicitly marked lossy; a lossless claim is forbidden otherwise.

AOS-FMT-007. Third-party exports are projections, not replacement authorities. Export MUST report omitted fields, truncation, unsupported relation kinds, clock conversions, downsampling, and other losses. W3C context or external span identity MUST not become the sole Alpha identity model.

24. AOS-JSON/1 reference interchange#

This section fixes one interoperable machine-readable representation while leaving fast native layouts to the implementer. It is an interchange/debugging format, not a required GPU or hot-path format.

24.1 Stream framing#

AOS-JSON-001. AOS-JSON/1 is UTF-8 JSON following RFC 8259 [N7], with one complete JSON object per LF-terminated line. A literal LF inside a JSON string MUST be escaped. Writers MUST NOT emit a byte-order mark, comments, duplicate object names, or trailing commas. Readers MUST reject duplicate object names rather than choosing an arbitrary winner.

AOS-JSON-002. A stream starts with type: "header", followed by zero or more descriptor, event, artifact, or coverage records, and SHOULD finish with type: "footer". An unfinished live stream MAY lack a footer. A retained stream lacking one MUST be marked incomplete at the interchange level, without assuming its contained events are invalid.

AOS-JSON-003. Every line has format: "AOS-JSON/1" and type. Unknown optional line types MAY be retained/skipped with coverage reporting. Critical requirements are listed in required_extensions in the header and affected records. An unrecognized critical requirement MUST prevent a claim of full interpretation or validation.

AOS-JSON-004. All integer-valued protocol fields, including sequence, lengths, revisions when numeric, counts, and raw ticks, MUST be decimal strings, not JSON numbers. Unsigned form is 0 or a nonzero digit followed by digits; signed form adds an optional leading minus and forbids negative zero. Range is determined by the field schema. IDs are strings under their defined namespace rules.

24.2 Value representation#

AOS-JSON-005. Schema-governed payload values use the following tagged representations. Structural protocol objects have fixed named fields and need not themselves be wrapped as maps.

Hex strings MUST be lowercase and even-length; floating formats have exactly 8 or 16 hexadecimal digits. Float bits are the numerical bit pattern written most-significant hexadecimal digit first, independent of native byte order. Conversion through a host JSON floating-point number is not permitted. Additional numeric formats require a versioned extension.

AOS-JSON-006. Availability slots are { "state": "present", "value": <value> } or { "state": <non-present status>, "reason": <optional structured reason> }. Non-present slots MUST NOT carry a fabricated value. A payload slot's present value is a tagged value; protocol slots such as time and context have their documented structural type.

24.3 Header and event#

A header MUST contain format/type, AOS semantic version, bundle identity, exporter implementation identity, and required extensions. It SHOULD declare stream limits and source native encodings. Descriptor records MUST contain an immutable ID, descriptor kind/schema, and descriptor body. Core event envelope fields from Section 7 are REQUIRED.

Illustrative header:

{"format":"AOS-JSON/1","type":"header","aos_version":"1.0","bundle_id":"11111111111111111111111111111111","exporter":"alpha-observe/example-build","required_extensions":[]}

Illustrative event, with referenced descriptors supplied elsewhere in the stream or bundle:

{
  "format": "AOS-JSON/1",
  "type": "event",
  "aos_version": "1.0",
  "event_id": {
    "attempt_id": "22222222222222222222222222222222",
    "producer_id": "33333333333333333333333333333333",
    "producer_epoch": "44444444444444444444444444444444",
    "sequence": "819"
  },
  "schema_id": "aos.execution.completion_observed@1.0",
  "record_class": "event",
  "policy_id": "55555555555555555555555555555555",
  "origin": {
    "kind": "direct",
    "provider_id": "66666666666666666666666666666666",
    "method": "host-completion-token-read"
  },
  "time": {
    "state": "present",
    "value": {
      "clock_id": "77777777777777777777777777777777",
      "clock_epoch": "88888888888888888888888888888888",
      "ticks": "12000000500"
    }
  },
  "context": {"state": "not_recorded"},
  "payload": {
    "submission": {"t":"ref","kind":"submission","id":"99999999999999999999999999999999"},
    "observed_status": {"t":"text","v":"completed"},
    "device_duration": {"state":"unavailable","reason":{"code":"not-measured"}}
  },
  "extensions": [],
  "required_extensions": []
}

The pretty formatting is explanatory; an actual AOS-JSON/1 stream writes that event on one line. Repeated-digit example IDs are placeholders, not an ID-generation recommendation. The event reports host observation of a completion token, not a measured GPU duration or validated tensor result.

24.4 Integrity and round trips#

AOS-JSON-007. JSON object order and whitespace are not semantic. AOS-JSON/1 alone is not a canonical signing or content-hash encoding. An artifact MAY be identified by the exact bytes of an exported stream, but a semantic digest MUST name a separate canonicalization profile. Generic parse-and-reserialize MUST NOT be assumed to preserve such a byte digest.

AOS-JSON-008. A footer MUST state the number of preceding lines/records covered, exporter termination status, declared omissions, and interchange completeness. It MAY reference an exact-byte digest manifest. Exporter completeness is not a claim of complete original acquisition.

AOS-JSON-009. A conforming reader MUST implement configurable finite line-size, string-size, collection, depth, and artifact-reference limits and report exceeded limits explicitly. Interoperating endpoints MUST advertise or document accepted limits. Bulk data SHOULD be separate artifacts rather than extremely large JSON lines.

AOS-JSON-010. Native → AOS-JSON/1 → native conversion MUST preserve event identities, exact supported numeric/byte values, descriptors, policy/clock attribution, relation meaning, and availability states for any declared lossless conversion. Native byte identity is not required unless a separate byte-preserving profile is claimed.

25. Ingestion, transport, and synchronization#

AOS-ING-001. Ingestion MUST validate framing, resource limits, schema identity, producer scope, and integrity before admitting data to authoritative storage. It MUST be able to quarantine malformed/conflicting records without crashing other producers or silently discarding diagnostics about the failure.

AOS-ING-002. Transport MUST identify stream incarnation, encoding/schema capabilities, chunk or record identity, sequence coverage, payload extent, integrity, and acknowledgement level. Batching/compression MAY vary without changing event identity.

AOS-ING-003. Retransmission MUST be idempotent at the declared ingest boundary. Receiving the same identity with equivalent content is a duplicate. Receiving the same identity with conflicting content is an integrity/identity conflict and MUST NOT be silently resolved by last-writer-wins.

AOS-ING-004. Acknowledgements MUST state received, validated, durably_stored, or a stronger explicitly defined replicated level. Upload queues MUST not delete the only source copy on a weaker acknowledgement than the configured retention contract requires.

AOS-ING-005. Reconnection MUST support resume from known committed ranges or chunks. Out-of-order transport MAY be accepted; it MUST not create an unjustified sequence-completeness claim. Transport ordering is not cross-producer execution ordering.

AOS-ING-006. Offline spooling MUST be bounded by storage policy. Retry MUST use bounded concurrency and backoff, and be cancellable. A remote outage MUST not silently grow storage forever or block optional capture indefinitely.

AOS-ING-007. Remote acquisition/collection MUST be opt-in. Endpoints, authorization scope, permitted data classes, and egress rules MUST be explicit. Local-only mode MUST not attempt DNS, discovery, updates, analytics, or uploads.

AOS-ING-008. The implementer MAY select standard transport protocols. A custom native transport requires a documented versioned framing, negotiation, error, and replay contract. New cryptographic constructions are not part of this standard.

26. Indexing, aggregation, retention, and deletion#

26.1 Derived indexes#

AOS-STORE-001. Indexes and materialized views MUST be rebuildable from retained authoritative segments, descriptors, and artifacts, subject to explicit retention. Index version, source coverage, and build/reducer identity MUST be queryable.

AOS-STORE-002. An index MUST NOT be the only retained authority for data it claims can be reconstructed. Corrupt or stale indexes MUST be detected or invalidated and MAY be rebuilt without changing original records.

AOS-STORE-003. Storage MUST support bounded queries by run/attempt, producer epoch, sequence/time window, schema/class, context/site, object/resource, metric/axis, diagnostic, artifact, and relation neighborhood for the capabilities it exposes. A specific indexing algorithm or database is not mandated.

26.2 Aggregation and compaction#

AOS-AGG-001. Every materialized aggregate MUST identify its reducer/version, input scope, watermark, grouping, weights, units, window semantics, and coverage. Exact, sampled, and approximate aggregates MUST remain distinguishable.

AOS-AGG-002. Compaction MUST preserve raw semantics when claimed lossless. A lossy compaction MUST publish an explicit derived representation and record what detail was removed. Retention of summaries alone MUST not be advertised as retention of full traces.

AOS-AGG-003. Deduplication, correction application, late-arriving data, and retractions MUST have deterministic reducer behavior. A query snapshot MUST not mix incompatible generations of an aggregate without disclosure.

26.3 Retention and deletion#

AOS-RET-001. Retention MUST be configurable independently for journals, traces, artifacts, indexes, and sensitive payloads, subject to explicit dependency rules. Retaining events SHOULD retain the descriptors needed to interpret them; missing dependencies MUST be reported.

AOS-RET-002. Garbage collection MUST respect pinned runs/artifacts, in-flight capture/upload, shared content references, and authorized retention holds. A checkpoint required for an active continuation MUST not be deleted merely because a generic trace TTL expired.

AOS-RET-003. Deletion MUST apply to authoritative bytes, indexes, caches, exported copies under management, replication, and backups according to a declared deletion scope and deadline. A logical tombstone MUST NOT be described as physical byte erasure.

AOS-RET-004. Redaction or removal from immutable retained data MUST create a sanitized version or delete the affected original according to policy. Exporting a sanitized copy does not itself delete the source. Retained removal/audit metadata MUST not preserve the sensitive payload it was intended to remove.

AOS-RET-005. A reader MUST distinguish expired data from never-recorded data where that fact is authorized and known. Retention MUST not silently transform a formerly complete evidence claim into an apparently still-complete one.

27. Query and investigation contract#

27.1 Query request and result#

AOS-QUERY-001. Machine queries MUST have explicit scope, filters, ordering, field projection, row/byte/work limits, timeout/cancellation, and continuation semantics. Potentially large traversals MUST be bounded by depth, node/edge count, and resource budget.

AOS-QUERY-002. Every result MUST carry schema/version, query identity or normalized request identity, source snapshot/watermark, freshness, coverage/completeness, unresolved references, warnings, result limits, and continuation token when applicable. Empty results MUST be distinguishable from incomplete, unavailable, and unauthorized results without leaking protected existence.

AOS-QUERY-003. Pagination MUST operate against a stable snapshot or explicitly report live-stream semantics. New ingest between pages MUST not silently duplicate/skip records under a claimed snapshot query. Continuation tokens MUST be bounded and scoped to the query and authorization context.

AOS-QUERY-004. Time filtering MUST state its clock/correlation domain and uncertainty treatment. A reader MUST not exclude relevant data by silently treating an unknown timestamp as zero. Sequence and logical-axis queries MUST remain available when time correlation is absent.

27.2 Required investigative capabilities#

A Core reader plus its relevant domain profiles MUST expose operations equivalent to the following. Exact command names, query language, and UI are implementation choices.

AOS-WHY-001. Explanation MUST distinguish static origin, dynamic occurrence, explicit dependency, observed error, and analytic hypothesis. Every material conclusion MUST reference retained records/artifacts or identify itself as an inference with a method.

AOS-WHY-002. A first-divergence query MUST report divergence at the observation resolution actually available. With sparse checkpoints it MAY establish only a range. It MUST not locate an exact first differing operation that was never observed.

AOS-WHY-003. Critical-path, bottleneck, leak, race, and root-cause analyses MUST name assumptions and evidence limits. Missing causal or lifetime events MUST weaken the result. A graph edge indicating possible dependence is not automatically proof of a performance cause.

28. Presentation and agent-facing interfaces#

AOS-UI-001. All presentation surfaces MUST derive from the same semantic reader/query contracts. A pretty dashboard MUST not implement divergent definitions of metric aggregation, completeness, or validation.

AOS-UI-002. Timelines and charts MUST visibly distinguish measured from estimated times, missing intervals, sampled populations, invalid values, and stale metrics. Smoothing and interpolated points MUST be identified as display transforms and MUST not alter exported raw values.

AOS-UI-003. Large traces MUST remain usable through bounded windows, pagination, aggregation, and progressive detail. Loading an entire long-running trace into memory MUST not be the only inspection path.

AOS-UI-004. Offline inspection MUST support text and structured output. Automated clients MUST receive stable field names and statuses rather than terminal escape codes or prose-only explanations. Numeric display formatting MUST not destroy exact underlying values.

AOS-UI-005. Agent-oriented results SHOULD support compact evidence bundles containing relevant subgraphs, records, code/source references, policies, and completeness metadata. Bundling MUST obey authorization, retention, and size budgets.

AOS-UI-006. Observation content is untrusted data. Renderers MUST escape terminal/browser control content. An agent consuming an artifact or diagnostic MUST not treat embedded instructions as authority to execute tools or change capture/security policy.

AOS-UI-007. Read-only investigation MUST be separable from control actions. Changing a capture policy, deleting data, replaying side effects, or launching a validation job with external effects requires its appropriate authorization and audit event.

29. Security, privacy, and trust boundaries#

AOS-SEC-001. The system MUST treat trace content, schema descriptors, artifact references, imported context, and remote producers as untrusted input at their respective trust boundaries. Bounds checking and authorization MUST occur before allocating large resources or following references.

AOS-SEC-002. Fields and artifacts MUST support privacy classification and collection/export restrictions. Classification MUST propagate through derived records unless an authorized sanitization rule explicitly changes it. Combining two innocuous fields MAY create sensitive information; schema owners MUST document known composition risks.

AOS-SEC-003. Credentials, secrets, private keys, access tokens, and unrestricted environment dumps MUST be excluded by default. Raw prompts, documents, datasets, memory, source content, tensor values, and device addresses MUST require explicit capture policy where sensitive. A filename or digest MUST not be assumed harmless.

AOS-SEC-004. Redaction SHOULD happen before sensitive content enters a general-purpose buffer or persistent store. Redaction MUST preserve a non-present/redacted state and applicable schema meaning rather than replacing the content with a misleading measured value.

AOS-SEC-005. A single-user local deployment MUST apply restrictive ownership/permissions to stored runs and control endpoints. A multi-user deployment MUST enforce authentication, authorization, tenant/owner isolation, query filtering, artifact access, and quotas. Anonymous remote administration MUST not be enabled by default.

AOS-SEC-006. Read, export, annotate, validate, change policy, delete, administer, and replay external effects MUST have separable capabilities. Knowing an event or content hash MUST not confer access. Authorization MUST apply to indexes, relation traversal, aggregates, and cached results as well as raw files.

AOS-SEC-007. Network profiles MUST declare encryption/authentication mechanisms, key ownership, rotation/revocation, and endpoint trust. Implementers MUST use established cryptographic algorithms and protocols rather than inventing cryptography. Unqualified cryptographic or transport support MUST be reported as such and MUST not be labelled compliant secure remote operation.

AOS-SEC-008. Hashing identifies or detects changes to specified bytes; it is not an authentication or producer-trust mechanism. Optional signatures or attestations MUST identify algorithm, signed representation, signer/trust anchor, verification result, and failure/revocation semantics. Tamper-evident history MUST not be advertised as tamper-proof storage.

AOS-SEC-009. Artifact paths and references MUST be resolved through authorized storage providers, with protection against directory traversal, symlink escape, arbitrary URL fetching, and credential leakage. Import MUST not fetch external content automatically unless policy permits that provider and destination.

AOS-SEC-010. Security-relevant control operations MUST have bounded auditable records. Audit records follow their own declared durability and failure policy. A privileged actor able to alter the recorder, its keys, and its storage is outside any stronger trust claim unless a separate attestation boundary is defined.

30. Validation, proof, and evidence receipts#

30.1 Receipt structure#

AOS-EVID-001. A validation receipt MUST identify the claim, claim schema/version, subject identities, validator implementation/build, input records/artifacts, capture/coverage requirements, assumptions, environment/target when relevant, method, verdict, and produced evidence artifacts.

AOS-EVID-002. Verdict MUST distinguish pass, fail, inconclusive, unsupported, and invalid_input. A validator crash or timeout MUST be represented as a failed validation attempt or inconclusive outcome, not evidence that the subject passed or failed its scientific claim.

AOS-EVID-003. The validation attempt's operational outcome and the claim verdict MUST be separate. A validator can execute successfully and conclude that data are incomplete. A failing claim can be supported by a successfully produced receipt.

30.2 Strength of evidence#

AOS-EVID-004. A receipt MUST identify whether its method is a structural check, executable test, differential test, simulation/model evaluation, formal proof check, physical observation, or another defined method. These methods MUST not be promoted into one another by renaming their output.

AOS-EVID-005. A formal proof receipt MUST identify proposition, proof/checker or kernel identity, checked artifact, assumptions/axioms, and the boundary between the mathematical model and the physical implementation. A boolean flag or constructor named Proof is not automatically a checked proof.

AOS-EVID-006. A physical receipt MUST identify the actual device/provider/build/input scope observed. A successful source check, native encoding test, or simulation MUST not satisfy a physical acquisition requirement. Physical observations still depend on the trust and semantics of their acquisition mechanism.

AOS-EVID-007. A claim requiring complete inputs MUST not pass on missing, unknown-critical-schema, corrupt, unauthorized, or incompatible evidence. Claims that legitimately use partial data MUST explicitly state that weaker scope.

AOS-EVID-008. Receipts MUST be reproducible from retained inputs when their method permits replay. Non-replayable external observations MUST state that limitation. Revalidation MUST create a new receipt rather than mutate the old verdict.

30.3 Required proof/test obligations#

The implementation SHOULD formalize invariants where Alpha can express and check them, including codec round trips, bounded frame arithmetic, disjoint capture regions, valid ownership transfer, sequence uniqueness, allowed state transitions, descriptor scope, and recovery-prefix properties. It SHOULD establish selection/loss conservation under a clearly stated producer model.

AOS-EVID-009. Formalization MUST not substitute for native and physical tests of the lowering, ABI, memory ordering, driver path, or filesystem behavior outside the formal model. Conversely, passing one physical test MUST not be described as proof for every input or architecture.

31. Performance, overhead, and noninterference#

31.1 Cost model#

AOS-PERF-001. Capture profiles MUST declare resource budgets and an overhead-measurement method. Targets MAY be chosen after baseline measurement, but they MUST be numerical, scoped, and accompanied by test conditions before an implementation claims to meet them.

AOS-PERF-002. Measurements MUST distinguish producer instruction/latency cost, allocation behavior, clock-read cost, buffer publication, drain/encoding, synchronization, storage, network, query cost, and device perturbation. Moving work to a collector does not make that work free.

AOS-PERF-003. Qualification MUST include representative small/latency-sensitive, throughput-heavy, memory-constrained, and overloaded workloads where supported. Cold start, warm-up, steady state, draining, and shutdown MUST be distinguished. No universal zero-overhead claim is permitted from one benchmark.

AOS-PERF-004. Performance reports MUST identify baseline and instrumented build/configuration, capture policy, target/environment, repetitions, measurement method, retained raw observations, and uncertainty. Thermal/clock state and unrelated load SHOULD be controlled or recorded where material.

31.2 Noninterference#

AOS-NI-001. Optional capture MUST NOT intentionally alter model data, algorithmic RNG state, update ordering required by semantics, or externally visible computation results. It MUST not add hidden computation fallback paths. Capture failures MUST not masquerade as model failures unless the explicitly selected execution/evidence policy makes them fatal.

AOS-NI-002. Instrumentation MUST NOT change the meaning of required synchronization or extend object lifetimes invisibly. Added measurement passes and data copies MUST be visible in the execution/resource plan and budget.

AOS-NI-003. The implementation MUST test disabled instrumentation, normal instrumentation, focused instrumentation, and collector failure. Where deterministic behavior is promised, outputs and relevant checkpoints MUST be compared under that contract. For nondeterministic programs, comparison MUST use a justified equivalence or statistical criterion rather than assuming bit identity.

AOS-NI-004. Timing, interleaving, resource placement, and race manifestation can change under instrumentation. A claim of semantic noninterference MUST state its execution assumptions and MUST NOT claim identical scheduling or physical timing merely because tensor outputs matched.

AOS-NI-005. An exact “compiled out” claim requires generated-code/resource evidence for the relevant optional sites, payload evaluation, buffers, and native calls. A source-level false branch alone is insufficient.

32. Observability of the observer#

AOS-SELF-001. The recorder MUST expose bounded health data for accepted, excluded, dropped, coalesced, written, durable, uploaded, and rejected data; queue occupancy; producer stalls; drain latency; flush/sync failures; storage/cardinality pressure; missing descriptors; and active policy revisions where applicable.

AOS-SELF-002. The health mechanism MUST not recursively depend on an unbounded instance of itself. Independent counters/status pages, reserved slots, or another bounded scheme are permitted. Unknown crash-tail loss MUST remain unknown.

AOS-SELF-003. A live viewer MUST display recorder disconnect, stale data, backlog, and degraded capture. It MUST not keep a green “healthy” state indefinitely because no new failure record arrived.

AOS-SELF-004. Collector/indexer/validator resource usage MUST be separable from the observed application's usage where the platform allows attribution. Shared-resource effects MUST not be silently assigned to application work.

33. Deployment and operational behavior#

AOS-OPS-001. A supported local deployment MUST run offline and need no hosted service. A self-hosted deployment MUST permit all retained data, processing, schemas, validation, and administration to remain inside the operator's infrastructure. Air-gapped operation MUST not depend on remote license checks, fonts, analytics, or runtime downloads.

AOS-OPS-002. Process placement is implementation-defined: in-process, companion process, node service, or cluster collector are permitted. The chosen composition MUST document failure isolation, ownership, startup discovery, liveness, quotas, and shutdown semantics.

AOS-OPS-003. Containers and orchestrators MAY provide deployment and storage, but MUST not be required by the core local recorder. A cluster profile SHOULD support operator-managed secrets, persistent volumes, controlled egress, readiness/liveness, resource limits, and upgrade/backup/restore procedures without weakening AOS semantics.

AOS-OPS-004. Remote service unavailability MUST not prevent offline inspection of already retained local runs. Upgrade MUST preserve readable historical data or provide explicit versioned migration/export. A rollback MUST not silently consume a newer critical encoding it does not understand.

AOS-OPS-005. Unclean shutdown, maintenance, quota exhaustion, and backup/restore MUST have documented run and coverage consequences. Backup validation MUST include descriptors and artifact dependencies, not only event files.

AOS-OPS-006. Baseline deployment MUST not require rebuilding general-purpose infrastructure in Alpha before useful local capture works. Optional advanced services can be separate qualified profiles. Their absence MUST not be disguised as complete support.

34. Migration and compatibility#

AOS-MIG-001. The implementing agent MUST inspect current telemetry, diagnostics, effects, binary codecs, clock providers, artifact manifests, and persistence mechanisms before choosing ownership and migration. A previous audit is orientation, not a replacement for current source inspection.

AOS-MIG-002. Useful existing semantics MUST be preserved or explicitly mapped. Legacy formats such as any retained ALPHATEL, ALST, or ALPHATR versions MUST retain their actual clock, identity, counter, and evidence meanings. Missing legacy fields MUST remain unknown rather than filled with invented current values.

AOS-MIG-003. Migration MUST distinguish a real runtime observation from prebuilt metadata, static plan, historical README claim, mock, or simulated receipt. Importing bytes into a new container MUST not upgrade evidence maturity.

AOS-MIG-004. During dual emission, records MUST have a correlation mechanism to prevent double counting. Compatibility files and human-readable status files SHOULD become projections of the maintained stream rather than independent authorities.

AOS-MIG-005. Legacy readers MAY remain adapters. Breaking changes require versioned encodings/schemas, fixtures, documented compatibility, and an explicit conversion-loss report. Destructive in-place conversion of the only retained run is prohibited by default.

AOS-MIG-006. Existing immutable artifacts and source ownership MUST be respected. Refactoring MUST avoid duplicating runtimes in separate systems and MUST preserve dependency-direction rules. Required native support must be implemented in its maintained owner rather than hidden in a one-off host script.

35. Conformance tests and qualification#

35.1 General rules#

AOS-TEST-001. Every applicable MUST requirement MUST map to tests, a machine-checkable invariant, an inspection artifact, or a documented combination that establishes its scope. A requirement matrix MUST identify the exact implementation revision and evidence, not merely a checkbox.

AOS-TEST-002. Tests MUST distinguish reference/model execution, Alpha source checking, generated-native execution, and physical device execution. Test names are not evidence categories. Skipped/unavailable device tests MUST remain explicitly unqualified.

AOS-TEST-003. Validation MUST include positive, negative, boundary, compatibility, and failure cases. A golden encoder test alone is not a recorder test; a buffer algorithm model alone is not a memory-ordering qualification.

35.2 Minimum qualification catalogue#

AOS-TEST-004. Property/fuzz tests SHOULD cover decoder arithmetic, framing/recovery, schema evolution, buffer state machines, and deterministic reducers. They MUST enforce resource limits, not merely avoid crashes on small valid inputs.

AOS-TEST-005. Durability reports MUST name the actual fault model tested. Process termination, injected syscall failure, filesystem remount, host reset, and physical power loss are not interchangeable experiments. A report MUST not claim the strongest model when only a weaker one was exercised.

AOS-TEST-006. Release conformance MUST identify any unmet applicable requirement and any SHOULD deviation. “All tests pass” MUST not conceal a test suite that exercises only the model lane or silently skips physical paths.

36. Required implementation deliverables#

AOS-DEL-001. A conforming implementation delivery MUST include the maintained Alpha sources and integrations; machine-readable semantic schemas; native encoding specification(s); AOS-JSON/1 reader/writer; capability manifest; bounded local capture and inspection; migration mappings; and conformance evidence for claimed profiles.

AOS-DEL-002. Documentation MUST explain identity, clocks, coverage, loss, durability levels, capture cost, privacy, recovery, and replay limits with runnable examples. Examples MUST compile/run on their declared lane or be labelled pseudocode.

AOS-DEL-003. The repository MUST contain compatibility/golden fixtures, fault/recovery cases, performance comparison machinery, and a requirement-to-evidence matrix. Fixtures containing sensitive content MUST be synthetic or authorized.

AOS-DEL-004. Unsupported or incomplete capabilities MUST be discoverable through the same capability interface used by clients. Empty implementations, success-shaped placeholders, unused record definitions, and self-reported qualification flags do not satisfy runtime support.

AOS-DEL-005. Significant implementation decisions MUST be recorded in concise design records: what was chosen, why, alternatives rejected, conformance consequences, and the evidence supporting performance/correctness claims. The agent is free to make these decisions without asking for approval on every module or algorithm.

37. Domain schema catalogue#

The following catalogue defines required semantic homes, not a command to emit every record on every run. For each implemented domain capability, the provider MUST supply versioned schemas covering its relevant concepts. The implementer MAY combine or subdivide schemas while preserving the listed distinctions.

AOS-CAT-001. Each concrete schema definition MUST provide actual field names/types and example instances. This catalogue does not authorize semantically empty records containing only arbitrary prose. A domain owner MAY add new concepts without modifying the core envelope when existing value and relation semantics suffice.

38. End-to-end reference scenarios#

These scenarios are acceptance narratives. They establish externally visible outcomes while allowing implementation freedom.

38.1 Compiler plan is not physical execution#

A system compiles successfully and emits a device image but is never executed. Inspection shows source closure, transformations, target plan, executable artifact, and build checks. It MUST NOT show device completion, a trained model, or device-tested qualification. An explanation can trace the image to source, but no runtime occurrence is invented.

38.2 Normal local training with asynchronous collection#

A run records configuration, build/input identities, named progress axes, selected metric aggregates, and checkpoint publication. The collector drains in batches; the training producer reports buffer acceptance rather than durable storage. Source sample time remains attached to delayed metrics. A later inspection shows which journal ranges and artifacts are durable and which detailed traces were sampled.

38.3 Numerical anomaly with focused capture#

A qualified numeric check detects a nonfinite value at a known tensor version. It records the anomaly, and an authorized policy requests a bounded focused window. The query includes only pre-trigger detail that the flight recorder actually retained. A delayed tensor capture MUST either capture the correct retained version or disclose that the version is no longer available. Any corrective model action remains a separate event.

38.4 Recorder overload without execution deadlock#

A high-rate trace fills its bounded buffer while the collector stalls. Optional records are dropped/coalesced/overwritten under policy; counters or gaps report the loss. Resource consumption remains bounded, required device cleanup proceeds, and the viewer shows degraded coverage. Required-evidence work is separately rejected or fails qualification according to admission policy.

38.5 Worker death and reconnect#

One worker disappears during a distributed operation. Other streams remain readable. Its final state and tail coverage remain unknown until surviving evidence establishes more. A restarted worker has a new producer epoch and appropriate attempt/membership context. Resending a previously stored chunk does not duplicate metrics; conflicting same-identity content is rejected/quarantined.

38.6 Crash during checkpoint publication#

A process dies after writing some checkpoint bytes but before the commit boundary. Recovery exposes any valid preceding history and the incomplete checkpoint intent. It MUST NOT offer the incomplete file as a valid published checkpoint or create a success record. A prior committed checkpoint remains eligible for restoration under its compatibility contract.

38.7 Mixed clocks and unsupported device timing#

Host completion-token reads are available but device timestamps are not. The timeline shows host submission and completion-observation intervals, with device duration unavailable. Cross-host views use explicit correlation uncertainty or separate axes. A query MUST not fabricate a precise GPU critical path from host polling alone.

38.8 Historical trace migration#

A legacy trace lacks producer epoch and reliable clock metadata. The importer assigns an import identity namespace, preserves original bytes/provenance, and reports missing original identity/clock properties. It MUST NOT imply the imported records originally carried the new fields or classify historical realtime stamps as monotonic.

38.9 Agent asks why a run slowed down#

A bounded explanation returns observed queue waits, changes in tensor/launch/layout versions, clock-valid intervals, relevant system samples, and capture gaps. It separates causal dependencies from statistical overlap. A proposed bottleneck is labelled an inference unless directly established. Missing observations lead to a bounded range or inconclusive answer, not an invented root cause.

38.10 Optional capture disabled#

The same deterministic workload is built with optional capture disabled and enabled. Qualification compares the appropriate outputs, RNG/state behavior, checkpoint semantics, and generated-resource differences. Disabled capture MUST not evaluate trace-only tensor summaries. The report distinguishes computational equivalence from measured timing/scheduling changes.

38.11 Sensitive artifact export and deletion#

A user exports a run with raw prompts/tensors excluded. The exported bundle retains useful structure and explicit redacted fields. It MUST not include sensitive bytes in hidden payloads, indexes, raw source copies, or descriptors. Deleting the local original has a separate declared scope; the export operation alone does not claim deletion from backups or other stores.

38.12 Reader encounters a future required schema#

A reader can frame and retain a segment whose critical schema it cannot interpret. It exposes raw/opaque inspection, reports the missing capability, and refuses full validation of affected claims. It MAY still inspect unrelated supported records. It MUST not crash or announce that all evidence passed because the unfamiliar record was skipped.

39. Implementation charter#

Build the smallest coherent Alpha-native implementation that genuinely satisfies the selected profiles, then extend it without changing the core meanings. Prefer reusable maintained owners and explicit contracts over duplicated system-specific code. Use the repository's actual syntax, effect model, native lowering, package rules, tests, and qualification practices rather than copying pseudocode literally.

The implementing agent is authorized to make normal engineering decisions: select layouts, algorithms, concurrency models, buffer sizes, file organization, indexes, internal APIs, presentation, and sequencing. It SHOULD document significant choices and use measurements to decide performance tradeoffs. It need not preserve incidental module names from an earlier strategy if a better current-repository integration exists.

The agent MUST preserve these non-negotiable outcomes: truthful observations; stable scoped identity; explicit loss and uncertainty; separate static provenance and runtime occurrence; bounded capture; correct ownership/publication; declared durability; local-first operation; no hidden execution fallback; supported-domain extensibility; safe inspection; privacy; and reproducible scoped evidence.

Do not add empty support for every possible hardware target. Do not turn implementation into a dashboard-first project, a rewrite of all infrastructure, or a proliferation of proof-labelled placeholders. Do not claim the system complete because record types exist. Completion means actual supported producers emit meaningful records, the native recorder retains/recover them under its declared policy, the reader explains them correctly, and tests establish the claimed boundaries.

AOS-CHARTER-001. The final engineering handoff MUST state what was implemented, what was actually executed, which targets/profiles were qualified, measured overhead, remaining unsupported capabilities, deviations, and the exact commands/evidence needed to reproduce those results.

40. External references#

These references define particular external conventions or interfaces. They do not endorse a hosted product or make an external SDK mandatory. Versioned references below are intentional; implementing an optional adapter to a different version requires an explicit compatibility declaration.

[N1] RFC 2119, Key words for use in RFCs to Indicate Requirement Levels, March 1997. Used only for normative requirement vocabulary.
https://www.rfc-editor.org/rfc/rfc2119

[N2] RFC 8174, Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words, May 2017. Used with RFC 2119 for BCP 14 capitalization.
https://www.rfc-editor.org/rfc/rfc8174

[N3] Linux man-pages, write(2). Platform reference for partial writes, returned progress, error handling, and the distinction between write success and persistence.
https://man7.org/linux/man-pages/man2/write.2.html

[N4] Linux man-pages, fsync(2). Platform reference for file/data synchronization and directory-entry synchronization. A non-Linux provider MUST document its corresponding actual contract.
https://man7.org/linux/man-pages/man2/fsync.2.html

[N5] W3C, Trace Context, Recommendation of 23 November 2021. Optional HTTP-context adapter reference, not Alpha's native object/provenance model.
https://www.w3.org/TR/2021/REC-trace-context-1-20211123/

[N6] NIST FIPS 180-4, Secure Hash Standard, August 2015 publication. Algorithm reference for the baseline SHA-256 content digest; not a claim of module certification or authentication.
https://csrc.nist.gov/pubs/fips/180-4/upd1/final

[N7] RFC 8259, The JavaScript Object Notation (JSON) Data Interchange Format, December 2017. Used by the stricter AOS-JSON/1 profile. Exact tagged integers and float bit patterns are AOS choices, not general JSON requirements.
https://www.rfc-editor.org/rfc/rfc8259

End of AOS 1.0 — Draft 1.