AQ-NRA-001 — AQ-NODE-01 Reference Architecture

SCOPE AND POSITION

AQ-NODE-01 is the reference article for the smallest unit of the Akasha-Q platform that carries all ten layers L0–L9 in some realisation. It is a trust and decision article, not an optical terminal: a terminal is the set of physical apertures, detectors and emitters that a node is built around. The architecture is defined once and is intended to hold unchanged across all six rungs of the reach ladder — optical bench, metro fibre and free-space, the 20–30 km relay, CubeSat, an operational LEO article, constellation. Only the enclosure, the environmental qualification set and the physical connector inventory change between rungs. If a rung requires a different boundary structure, that is a finding against this document, not a variant of it.

Components are named here by function and by the property that must be measured of them. No vendor, part number or supplier-specific interface appears in this document, deliberately: the architecture must survive a supply change without re-argument, and a part number in a reference architecture becomes an unstated assumption the moment the part is superseded.

            TB-1   PHYSICAL / SYSTEM BOUNDARY   (enforcement: physical)
  +-------------------------------------------------------------------+
  |  L0 PHYSICAL REALITY                                              |
  |   optical head | detector chain | environmental sensors | osc ref  |
  |        |              |               |                |           |
  +--------|--------------|---------------|----------------|----------+
           v              v               v                v
  ==== TB-2  DETERMINISTIC ACQUISITION (fixed-logic fabric) ===========
  |  timestamp AT capture | bound + health tests | frame sequencing   |
  |  emits: sample + t_acquired + health verdict + sequence number    |
  |  never holds: key material, policy, trust arbitration             |
  ====================================================================
           |   one direction only: measured records outward
           v
  ---- TB-3  TRUST REASONING (general-purpose compute) ---------------
  |  L1 entropy trust | L2 time discipline | L3 identity + keys       |
  |  L4 AQ-TSE-01 trust state engine                                  |
  |  L8 advisory analysis - annotation only, carries no authority     |
  --------------------------------------------------------------------
           |   decision request: Q1 Q2 Q3 (hard) then Q4 (reducing)
           v
  #### TB-4  DECISION / PHYSICAL EFFECT (hardware-gated) #############
  |  L5 command authority -> enable line -> emitter, actuator, key use|
  |  no software-only path can assert the enable line                 |
  ####################################################################
           |   every crossing of every boundary emits a record
           v
  ~~~~ TB-5  RUNTIME / EVIDENCE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  |  L6 evidence fabric (append-only) | L7 network + orchestration    |
  |  egress: records, chain heads, anchors. no inbound authority.     |
  |  L9 systems engineering + safety governance observes all of it    |
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

ENFORCEMENT CLASSES

A boundary is only as strong as the mechanism that enforces it, so each boundary is assigned one class and the class is stated wherever the boundary is discussed. EC-P physical — enclosure, connector inventory, aperture, tamper evidence. EC-D deterministic logic — fixed-function fabric whose timing is bounded by construction. EC-C cryptographic — signature or authenticated-encryption check whose failure is a hard refusal. EC-S software-mediated — process, privilege and interface separation on a scheduled processor. EC-A procedural — a written, logged human procedure.

TRUST BOUNDARIES TB-1 – TB-5

ELEMENT CLASSIFICATION

Every element is classified on five axes so that a reader can tell, without reading the implementation, what kind of thing it is and what kind of claim its output can support.

WHY A FIXED-LOGIC ACQUISITION FABRIC

The acquisition fabric exists for two reasons and no others. First, a timestamp applied at the point of acquisition is the only timestamp that can honestly be tagged MEASURED under DC-1; a timestamp applied after a general-purpose scheduler has handled the sample records when software noticed the event, which is a different quantity and must be tagged DERIVED. Second, health and bound tests that must not be deferred — detector saturation, bias excursion, reference loss, frame discontinuity — run in fixed logic so that their execution interval is bounded by construction rather than by scheduling policy. The achievable timestamp resolution, the distribution of its uncertainty, and the worst-case test interval are all quantities to be established by measurement on the bench rung and recorded as the first entries in the node's characterisation set. This document states no figure for any of them.

UPDATE BOUNDARY (SIGNATURE-GATED)

An update is any change to fabric configuration, software image, policy set, calibration set or key set. Every update is a consequential transition and is therefore fully reconstructable from the Evidence Fabric alone (DC-5). The signature check is a hard constraint at TB-5 ingress: an image whose signature does not verify is refused, and the refusal is itself a record; there is no operator override path that bypasses the check, because an override path is indistinguishable from the failure it is meant to survive.

   any state --+
               |  update proposed (signed, staged, not applied)
               v
        [ STAGED ]  --signature invalid--> refused, record written,
               |                           node state unchanged
               |  applied
               v
        [ RECOVERING ]   <-- the ONLY state an applied update may enter
               |
               |  full recovery sequence R-1..R-6, each step recorded
               |  and each step's failure recorded with its reason
               |
     +---------+---------+
     |                   |
  all steps pass     any step fails
     |                   |
     v                   v
  [ NORMAL ]      [ RESTRICTED | CRITICAL | DENY ]  per L4 policy

Trust does not survive an update. This is DC-4 applied to the node's own composition: trust falls on a single observation and rises only through the full recovery sequence, and an update is an observation that the node is no longer the article that earned the previous state. During RECOVERING, abstain is a permitted and expected outcome (DC-3); a node that answers execute for every request while recovering has a defect in L5, not a virtue.

CONFIGURATION IDENTITY

Configuration identity is a single digest, config_id, computed over a canonical manifest containing: the hardware inventory record and its serialised connector inventory; the acquisition fabric image digest; every software image digest; the policy set digest; the calibration set digest; the public identifiers of the key set in custody; and the boundary enforcement manifest, which states the enforcement class actually realised for each of TB-1–TB-5 on this rung. The manifest is signed by the authority that released the configuration, and config_id is recomputed by the node at every entry to RECOVERING and at a defined interval thereafter.

Every record in the Evidence Fabric binds config_id (AQ-EFD-000 § record skeleton). This is what makes a measurement re-interpretable years later: a value is meaningless without the article and calibration that produced it, and a value whose configuration cannot be named is evidence of an event, not evidence of a quantity.