AD‑10 [TC] — Timing Integrity & Covert Channels (RTS / ETG / TIG)

Aliases: None Cluster: Kernel (base) Depends on: AD‑01 [OV], AD‑05 [MRP], AD‑08 [SO], AD‑09 [WB]

0. For humans

What question does this answer?

"How do we make sure the system is not leaking extra information through when it speaks, not just what it says?"

How do I know it's live?

You can point to:

• A configured Real‑Time Scheduler (RTS) with explicit modes (CT‑Strict, CT‑Batch, etc.), visible in FHR as rts_mode.
• An Emission Timing Gate (ETG) that quantises emissions into a small number of latency buckets, keeping distribution close to a host‑side baseline.
• A Timing Integrity Gate (TIG) that continuously tests timing distributions (χ² / MI), raising a hard trip when they drift into likely covert-channel territory.
• A Watchdog + Halt Budget (AD‑09 [WB]) that, on TIG trip, halts streaming within ≤5 tokens and logs WATCHDOG_TRIP.

Where do I see it?

• FHR / logs: rts_mode, streaming_mode, latency_bucket, latency_bucket_hist, latency_chi2_p, mi_latency_content_est, etg_active, tig_breach, watchdog_trip, timing_op_point_id, timing_incidents[].
• Dashboards: latency panel (observed vs baseline histograms, χ² p‑value trends, MI trend), halt panel (p95/p99 halt tokens), mode panel (rts_mode distribution).

Quick checklist

• Implemented if: CT‑profile present; ETG enforcing quantisation; TIG tests running; trip → halt within ≤5 tokens.
• Key artefacts: RTS profile definitions, ETG baseline distributions, TIG threshold configuration.
• Key FHR fields: rts_mode, tig_breach, watchdog_trip, latency_chi2_p, mi_latency_content_est.
• Key failure codes: TIMING_COVERT_CHANNEL, TIMING_DISTRIBUTION_ANOMALY, WATCHDOG_TRIP.
• Escalation path: TIG trip → watchdog halt → Degraded Safe Mode → AD‑12 [OP] incident.

1. Purpose & scope

AD‑10 [TC] defines:

1. The Real‑Time Scheduler (RTS) with explicit constant‑time modes so latency patterns cannot encode content.
2. The Emission Timing Gate (ETG) that quantises emissions into latency buckets and enforces baseline distribution fidelity.
3. The Timing Integrity Gate (TIG) that applies statistical tests (χ² distribution test + MI content‑correlation test) and raises hard trips when timing patterns suggest covert channels.
4. The interaction with the watchdog (AD‑09 [WB]) for halt enforcement on TIG trips.
5. The sensitivity / UX trade-off that makes timing enforcement posture inspectable and deployment-specific.

2. Real‑Time Scheduler (RTS)

RTS defines how tokens are released to the user. Modes include:

• CT‑Strict: constant‑time per token; highest covert‑channel resistance; highest latency cost.
• CT‑Batch: constant‑time per chunk; moderate resistance; better throughput.
• Additional deployment‑defined modes within the timing profile.

All timing‑sensitive deployments must use at least one CT profile by default. The mode is logged as rts_mode in FHR.

3. Emission Timing Gate (ETG)

ETG quantises emission times into a small number of latency buckets. Key properties:

• There is a versioned baseline distribution per rts_mode / timing_op_point_id.
• Content code cannot directly select latency buckets.
• etg_active in FHR records whether ETG is enforcing.

4. Timing Integrity Gate (TIG)

TIG continuously tests timing distributions using:

1. Distribution tests (e.g. χ² vs baseline): detect when the observed latency pattern deviates from the expected schedule.
2. Content‑correlation tests (MI estimate): detect when timing correlates with content in ways that suggest information leakage.

When both tests flag a pattern beyond configured thresholds → hard trip. On TIG hard trip: the watchdog halts streaming within ≤5 tokens (AD‑09 [WB]); uncommitted kernel-owned state rolls back; runtime_mode = degraded; any dispatched external effect is reconciled from the durable operation ledger and receipt; and the event is logged as tig_breach + WATCHDOG_TRIP + timing incident code. The deployment may enforce a stricter RTS profile immediately. Any change from full to MKP is a separate governed architecture-profile change, never an alias for runtime degradation.

5. Sensitivity / UX trade‑off clause

Timing‑channel protection introduces a tunable trade‑off between covert‑channel sensitivity and user‑facing interruption burden. Aggressive timing enforcement (low p‑value thresholds on χ² tests, tight MI bands) reduces covert‑channel risk but increases false‑positive trip rates, each of which interrupts the user's experience with a streaming halt and a Degraded Safe Mode explanation.

5.1 Deployment‑declared profiles

Each deployment must declare a timing sensitivity profile:

• conservative — wider bands, higher p‑value thresholds; fewer false trips, slightly more covert‑channel exposure. Appropriate for low‑risk, high‑throughput deployments.
• balanced — default profile; trade‑off calibrated for general use.
• strict — narrow bands, low p‑value thresholds; more false trips, tighter covert‑channel control. Appropriate for high‑security or regulated deployments.

5.2 False‑positive budget

A declared timing_fp_budget (acceptable false‑trip rate per session or per deployment window) is: monitored via FHR fields, used to calibrate TIG thresholds during tuning, reported alongside true‑positive rates in challenge suite results (AD‑03 [CS] / AD‑19 [CI]).

5.3 FHR fields (sensitivity)

• timing_sensitivity_profile ∈ {conservative, balanced, strict}.
• timing_fp_budget: declared acceptable false‑trip rate.
• timing_fp_suspected: count of trips subsequently classified as likely false positives.
• timing_interrupt_count: total timing‑related streaming halts this session.
• timing_interrupt_recovery_ms: time from halt to resumed interaction.

5.4 Invariant

The sensitivity/UX trade‑off is inspectable and deployment‑specific. No deployment may hide its timing enforcement posture; the profile and FP budget must be visible in FHR and available to auditors.

5.5 Tunable

Exact thresholds, p‑value boundaries, and FP budget values per profile, as long as they are documented, justified, and visible.

6. FHR fields & events

Per turn (FHR): rts_mode, streaming_mode (streaming/batch), release_interval_ms, latency_bucket, latency_bucket_hist, latency_chi2_p, mi_latency_content_est, etg_active, tig_breach, watchdog_trip, timing_op_point_id, timing_incidents[].

Timing sensitivity fields (§5.3): timing_sensitivity_profile, timing_fp_budget, timing_fp_suspected, timing_interrupt_count, timing_interrupt_recovery_ms.

Optional: halt_tokens_post_trip, halt_latency_ms.

Failure codes: TIMING_COVERT_CHANNEL, TIMING_DISTRIBUTION_ANOMALY, COMPUTE_BUDGET_EXCEEDED, WATCHDOG_TRIP.

7. MKP view

In MKP: timing controls do not go away. MKP must still enforce a CT RTS profile, ETG quantisation, TIG tests, and watchdog halts. MKP might use simpler tests (fewer buckets, coarser MI estimates) but cannot drop timing‑channel mitigation entirely.

8. Invariants vs configurable degrees of freedom

Hard invariants:

1. CT‑profile presence. At least one constant‑time RTS profile exists, and timing‑sensitive deployments use it by default.
2. ETG enforcement. Emission times are quantised; versioned baseline per mode; content code cannot directly select latency buckets.
3. TIG statistical guard. Both distribution tests and content‑correlation tests are in place; at least one hard trip condition configured.
4. Trip → halt. On TIG hard trip: watchdog halts within ≤5 tokens; uncommitted kernel-owned state rolls back; runtime_mode = degraded; dispatched external effects reconcile from their receipts; event logged with timing incident code.
5. Observability. FHR includes timing fields.
6. Sensitivity inspectability. Timing sensitivity profile and FP budget are declared, documented, and visible in FHR.

Configurable degrees of freedom:

• RTS exact profiles (bucket boundaries, tick intervals, CT‑Strict vs CT‑Batch).
• Statistical thresholds (χ² p‑value threshold, window size, MI thresholds).
• Trip hysteresis & debounce.
• Whether operators subsequently authorize a profile change to MKP; the TIG trip itself only sets degraded runtime mode and may enforce stricter RTS within the current profile.
• Sensitivity profile values per deployment.

The system can be made stricter but not looser in ways that compromise covert‑channel guarantees while claiming compliance.

9. Interfaces & cross-links

• AD‑01 [OV]: timing integrity is part of the global invariant set.
• AD‑03 [CS]: timing/exfil challenge packs test covert‑channel detection.
• AD‑05 [MRP]: TIG trips feed Tier‑0/Tier‑2 signals into MPM.
• AD‑08 [SO]: hosts all timing FHR fields.
• AD‑09 [WB]: watchdog enforces halt budget on TIG trips.
• AD‑18 [SE]: runtime contract includes timing controls as part of TURN‑ACID wiring.
• AD‑19 [CI]: timing challenge suite as CI gate; precision parity includes timing behaviour.

10. Acceptance: when can you say "AD‑10 is implemented"?

You can claim AD‑10 [TC] is live if:

1. At least one CT RTS profile exists and timing‑sensitive traffic uses it.
2. ETG quantises emissions; baseline distributions are versioned and logged.
3. TIG tests (χ² + MI) are running; at least one hard trip condition is active.
4. On TIG trip, halt occurs within ≤5 tokens, uncommitted kernel-owned state rolls back, degraded runtime mode is entered, dispatched effects reconcile, and the event is fully logged.
5. FHR exposes rts_mode, tig_breach, watchdog_trip, latency_chi2_p, mi_latency_content_est, timing_sensitivity_profile, and timing_fp_budget.

If timing controls exist but are not enforced, or if TIG is configured but never triggers because thresholds are set to infinity, then AD‑10 is not truly implemented.