AQ-ICD-REG-001 — Interface Control Document Register

PURPOSE AND STANDING

This register is the controlling index of the six Interface Control Documents that govern every crossing between the ten layers of the Akasha-Q architecture. It exists so that no two layers can be implemented against different beliefs about the same boundary. Nothing described in any of the six ICDs has been built, and no interface has been exercised against hardware; each ICD is a specification of intended behaviour at evidence level Concept or Theory. Where an ICD states a quantity, that quantity is a defined metric with an undefined value until bench measurement establishes one.

Rule of precedence: an ICD is authoritative over any layer document, any subsystem note and any implementation. Where a layer document and its ICD disagree, the ICD is correct and the layer document is defective.

STATUS LADDER

• S0 — outline: parties and boundary named, content not written.
• S1 — draft: full clause set present, internally inconsistent parts permitted.
• S2 — review: cross-layer review complete, open items logged. Minimum status for implementation work to begin.
• S3 — baselined at CA tier: change requires the L9 change authority.
• S4 — baselined at Y1 tier: content confirmed against measurement from the bootstrap laboratory.

REGISTER

Register custodian and change authority: L9 Systems Engineering & Safety Governance. L3 Identity & Cryptographic Trust and L8 AI-Assisted Analysis hold no ICD of their own: L3 obligations are carried as dependency clauses inside CMD, EVID and NET; L8 is advisory only and is prohibited from appearing in any input contract, which is a schema-level prohibition rather than a runtime check.

ICD BOUNDARY MAP

 TB-1  +--------------------------------------------------+
 phys  |  L0 Physical Reality | L1 Sensing & Entropy Trust |
       +-----------------------+--------------------------+
                               |  AQ-ICD-PHY-001
                               v
 TB-2  +--------------------------------------------------+
 acq   |  FPGA deterministic acquisition + timestamping    |
       +--------+--------------------------------+--------+
                | AQ-ICD-TIME-001                |
                v                                |
 TB-3  +----------------------------+            |
 trust |  L4  AQ-TSE-01 trust state |            |
       +-------------+--------------+            |
                     | AQ-ICD-TRUST-001          |
                     v                           |
 TB-4  +----------------------------+            |
 cmd   |  L5 command authority      |            |
  +hw  |  Q1 Q2 Q3 hard constraints |            |
       |  Q4 may only reduce        |            |
       +-------------+--------------+            |
                     | AQ-ICD-CMD-001            |
                     v                           v
 TB-5  +--------------------------------------------------+
 evid  |  L6 Evidence & Provenance Fabric (append-only)    |
       +-----------------------+--------------------------+
                               | AQ-ICD-EVID-001
                               v
       +--------------------------------------------------+
       |  L7 Network & Orchestration   AQ-ICD-NET-001     |
       +--------------------------------------------------+

  L8 advisory analysis reads the Evidence Fabric only.
  No ICD defines a path from L8 into L4 or L5.

MANDATORY CONTENT — EVERY ICD

No ICD may reach S2 without all ten clauses present. Clauses 5 and 6 are the ones integration reliably gets wrong and are non-waivable.

• C1 Parties and boundary — producing article, consuming article, the trust boundary crossed, and what may not cross it.
• C2 Data dictionary — every field with unit, range, encoding and a mandatory DC-1 tag (MEASURED / DERIVED / MODELLED). A field that can never be MEASURED is declared so at the interface, not at the consumer.
• C3 Temporal validity — issue time, validity window, maximum accepted age, and the timestamp uncertainty that accompanies the value.
• C4 Versioning — compatibility rule, how an unknown field is treated, and the prohibition on silent reinterpretation of an existing field.
• C5 Failure semantics — each failure class the producer can experience, its wire encoding, and the required consumer behaviour. Each row cites its entry in the failure catalogue (F-1..F-14).
• C6 Absence semantics — the encoding of undetermined, the staleness threshold at which a held value becomes undetermined, and behaviour on partial delivery. Absence is never encoded as a nominal value, a zero, or a default (DC-2).
• C7 Overload behaviour — saturation, backpressure and shed policy, and which side loses data first.
• C8 Named assumption set — the security, environmental and adversary assumptions under which the stated behaviour holds, cited by name, plus the required behaviour outside that envelope.
• C9 Evidence obligation — which crossings emit a record to AQ-ICD-EVID-001, and which crossings must not proceed until acceptance is returned (DC-5).
• C10 Conformance vectors — test vectors including at least one refusal case per failure class and per absence condition. An implementation that cannot refuse is not conformant.

AQ-ICD-PHY-001 — PRE-IMPLEMENTATION CONTENT

• Channel inventory: physical quantity, unit, transducer identity, calibration record reference, permitted DC-1 tag class per channel.
• Electrical and optical definition: connector, level, impedance, polarity, grounding, and the mechanical reference frame each measurement is expressed in.
• Frame construction: header, channel map, sequence number, acquisition-window boundary, and the rule that decides which timestamp from AQ-ICD-TIME-001 is authoritative for a frame.
• Entropy channel: raw versus conditioned separation, which side of TB-2 conditioning occurs on, and online health-test result encoding. A failed health test is transported as an explicit result, never as an absent field.
• Calibration and drift: how a record is referenced from a frame; behaviour when the reference is expired or unknown.
• Failure semantics: transducer fault, acquisition overrun, link loss, calibration expiry, saturation, clipping, blocked or dark channel — each a distinct code, never a zero value.
• Absence semantics: per-channel undetermined, maximum held-value age, partial-frame handling. A dropped channel does not shrink the frame silently.
• Trust interaction: this interface may request a trust-state effect; it may never assert one. The transition is owned by AQ-ICD-TRUST-001.

AQ-ICD-TIME-001 — PRE-IMPLEMENTATION CONTENT

• Time scale, epoch, representation; the distinction between a timestamp's resolution and its uncertainty, with the uncertainty field mandatory and non-omissible.
• Clock authority at each boundary and how authority is transferred; behaviour when two sources disagree, cited to the conflict catalogue (CF-1..CF-7).
• Discipline state as an enumerated value carried with every consumer contract: disciplined, free-running, holdover, unsynchronised.
• Holdover accounting: elapsed holdover and modelled drift reported as DERIVED or MODELLED, never as MEASURED.
• Ordering and monotonicity across TB-2 → TB-3 → TB-5, and the defined behaviour on a backwards step.
• Absence semantics: no timestamp, stale timestamp, and unknown-uncertainty timestamp are three conditions with three encodings. None may be substituted by a plausible value.
• Failure semantics: reference loss, step event, oscillator fault, frame arriving outside its acquisition window.
• Metric definitions to be measured — offset, stability over a stated averaging interval, holdover growth, end-to-end timestamp uncertainty budget — each recorded here as a defined metric whose target is established only from bench measurement.

AQ-ICD-TRUST-001 — PRE-IMPLEMENTATION CONTENT

• Closed input contract: the exact observations that may reach AQ-TSE-01, each with source ICD, DC-1 tag, validity window and absence encoding. Extension by change control only.
• Output contract: state (NORMAL / RESTRICTED / CRITICAL / DENY / RECOVERING), the observation set that produced it, and a reconstruction handle into the Evidence Fabric.
• DC-4 as an interface obligation: one qualifying observation is sufficient to lower state; no message on this interface can raise state. Raising occurs only through the recovery sequence.
• Recovery sequence: ordered steps, who may initiate, evidence required per step, and the statement that RECOVERING is externally visible, not an internal detail.
• Absence semantics: an input that is missing, stale or of unknown provenance is carried as undetermined and treated as non-benign. The schema must make "absent" unencodable as "nominal".
• Advisory isolation: L8 output may be attached as an annotation on a trust record and may never appear in the input contract.
• Observe-only flag: the record states whether the emitted state was consumed by L5 or recorded only (see AQ-Y1A-001).
• Vectors: forced single-observation degradation, partial recovery, contradictory inputs, all-inputs-absent.

AQ-ICD-CMD-001 — PRE-IMPLEMENTATION CONTENT

• Command object: issuer identity, authorisation scope, validity window, replay protection, and the class of physical effect requested.
• Evaluation order Q1 → Q2 → Q3 → Q4, with Q1–Q3 as hard constraints. The encoding must make it structurally impossible for a Q4 result to widen what Q1–Q3 permitted.
• Outcome encoding: execute, execute-restricted, safe-hold, abstain, deny, each with a mandatory reason code and a decision-boundary citation (B-1..B-5).
• Abstention as a first-class outcome (DC-3). A consumer that cannot represent abstain fails conformance.
• Hardware gate contract at TB-4: the electrical condition that constitutes an authorised effect, and the fail-state on loss of the authorising signal — which must be the non-acting state.
• Absence semantics: missing trust state, expired authorisation, unreadable command resolve to deny or abstain per the boundary table. There is no path from absence to execute.
• Failure semantics: gate feedback mismatch, effect asserted without a matching decision record, decision record without a matching effect — all reportable on this interface.
• Evidence ordering: no effect may be asserted before the decision record is accepted by AQ-ICD-EVID-001.

AQ-ICD-EVID-001 — PRE-IMPLEMENTATION CONTENT

• Record schema per event class, with a DC-1 tag on every value.
• Append-only semantics, ordering, integrity chaining, and what a consumer may conclude from a gap.
• Acceptance contract: what "accepted" means, whether it is durable at acceptance, and the producer's obligation when acceptance is not returned — it must not proceed to a physical effect.
• Reconstruction contract (DC-5): the query set that must be sufficient to reconstruct any consequential transition from the fabric alone, with no access to live subsystem memory.
• Redaction and record-level access control, with the constraint that redaction never removes the existence of a record.
• Absence semantics: an expected record that did not arrive is itself an event. Silence is never evidence of nominal operation.
• Failure semantics: backpressure, storage exhaustion, integrity check failure — producers degrade the system rather than degrade the record.
• Retention, export format, long-term readability without the original toolchain.

AQ-ICD-NET-001 — PRE-IMPLEMENTATION CONTENT

• Node addressing in the AQ-NODE identifier form; membership definition for N=2 and an explicit statement of what is undefined beyond N=2 at the current tier.
• Transport independence: defined over a swap-ready transport contract; the bearer is a configuration item, not part of the interface.
• Session establishment and its L3 dependency; if authentication is incomplete, nothing that can influence a decision may be carried.
• Message classes and priority, and the prohibition on any network condition raising trust state.
• Absence semantics: partition, one-way reachability and delayed delivery are three encodings. An unheard peer is undetermined, not nominal.
• Failure semantics: duplication, reordering, replay, partial delivery, with required consumer behaviour for each.
• Orchestration commands are commands — they cross AQ-ICD-CMD-001 and are not a side channel.

IDENTIFIER EQUIVALENCE: AQ-NODE / AKQ-NODE

AQ-NODE-n is the canonical identifier form. The string AKQ-NODE-n appears in Parts up to and including Part 12 and denotes the same articles — it is a legacy spelling, not a distinct design, not a variant, and not a superseded article. No ICD, drawing, schema, test vector or evidence record may treat the two strings as different objects.

• No document written after Part 12 may introduce the AKQ- prefix. The legacy string is retained only inside quoted titles and verbatim citations of earlier Parts.
• Any tool that indexes identifiers must normalise AKQ-NODE-n to AQ-NODE-n at ingest and record that the normalisation occurred, so that provenance remains reconstructable.
• Discovery of two records that appear to describe different articles under the two spellings is a configuration defect and is raised to the L9 change authority, not resolved locally.

CHANGE CONTROL

Version increments below 1.0 require the owner role only. Any change at S3 or above, and any change to clauses C5, C6 or C9 at any status, requires the L9 change authority and a recorded impact assessment naming the affected failure-catalogue entries. A change that alters the meaning of an existing field without changing its name is prohibited outright; the field is deprecated and a new one introduced.