Sync, backup, read limiter and safe degradation

C0937Which copy of the data is the working one: the clinic's or the cloud's?

The sync, backup, read limiter and safe degradation part of the specification (REQ-3101) says the on-site database must be the operational primary; the cloud copy is an encrypted backup replica. No. The specification describes it, but the pilot does not include it. Acceptance check: cloud outage does not interrupt clinical use.

C0938What does a sync bundle contain, and how is it protected?

How would it be tested? The specification says gap injection triggers retransmission request; duplicate bundle rejected. That is the check for REQ-3102: the sync agent must produce signed, hash-chained, encrypted change bundles with gapless sequence numbers, replay protection and resumable upload. Not yet. It is designed in the specification and not built in the pilot.

C0939Can clinics sync directly with each other?

Designed, not built: there is no code for this in the pilot. For reference, REQ-3103 (a high-priority requirement, the medium and large tiers) says the sync pathway must support cloud sync and, where allowed by profile and consent, clinic-to-clinic sync. Check: clinic-to-clinic sync disabled unless profile and authority permit.

C0940What is the read-side limiter and what does it limit?

A read-side limiter on a node en route to the server must limit reads and pulls (not writes) using oscillating time windows. Window length, oscillation pattern and per-role/per-terminal quotas are (still an open decision). That is REQ-3104, a top-priority requirement for all three tiers. This is on the design side of the line. Nothing in v0.2.0 does it. Test in the specification: limiter config parameters exist and default to disabled-with-logging until set; when enabled, read counts above quota trip. Parts of it are explicitly marked as open in the specification.

C0941If the limiter trips, does the clinic stop working?

No. The specification describes it, but the pilot does not include it. REQ-3105 says tripping the limiter must pause only cloud sync and clinic-to-clinic sync; local operation must continue unaffected. Its acceptance check: while tripped, clinicians can view and write charts; sync state shows PAUSED.

C0942Does a detected integrity problem also pause sync?

REQ-3106 is a top-priority requirement for all three tiers: any integrity alarm must also pause sync (safe-degrade). Not yet. It is designed in the specification and not built in the pilot. To verify it, the specification says injected bundle-chain break pauses sync.

C0943Who has to approve resuming sync after a pause?

The sync, backup, read limiter and safe degradation part of the specification (REQ-3107) says resuming sync after a pause must require multi-key corroboration and an audit entry. Designed, not built: there is no code for this in the pilot. Acceptance check: resume attempt with one signer fails.

C0944Does AuroraMed pad bundle sizes and add batching jitter as a limited traffic-analysis countermeasure?

How would it be tested? The specification says observed bundle sizes fall into padding classes. That is the check for REQ-3108: the system must pad bundle sizes and add batching jitter as a limited traffic-analysis countermeasure. This is on the design side of the line. Nothing in v0.2.0 does it.

C0945How are backups tiered, and what makes them tamper-evident?

No. The specification describes it, but the pilot does not include it. For reference, REQ-3109 (a top-priority requirement, all three tiers) says the system must implement 3-2-1-1-0 backup tiers T0-T5 with immutable copy and offline copy, and must anchor backup ranges on the ledger. Check: anchor exists for each range; tamper of a bundle is detected on restore.

C0946How would a restored backup be checked before going live?

Restore must run in an isolated environment with signature/chain verification and dual authorization for promotion. That is REQ-3110, a top-priority requirement for all three tiers. Not yet. It is designed in the specification and not built in the pilot. Test in the specification: restore drill checklist passes.

C0947How does an erasure request reach the backups and replicas?

Designed, not built: there is no code for this in the pilot. REQ-3111 says erasure requests must propagate as tombstone bundles and key destruction events. Its acceptance check: restored backup lacks decryptable erased data.

C0948Does the pilot include the scroll-rate lock?

REQ-3112 is a top-priority requirement for all three tiers: the scroll-rate lock must require re-authentication when history-tab throughput exceeds the threshold (still an open decision), computed server-side by information rendered, with different weights for HISTORY and RESULTS_TRIAGE. This is on the design side of the line. Nothing in v0.2.0 does it. To verify it, the specification says scripted paging trips the lock; triage scrolling does not. Parts of it are explicitly marked as open in the specification.

C0949What relaxes in a declared emergency?

The sync, backup, read limiter and safe degradation part of the specification (REQ-3113) says emergency mode must relax history limits with full logging and no password prompt for patients in a declared emergency. No. The specification describes it, but the pilot does not include it. Acceptance check: break-glass patient shows relaxed limits and review item.

C0950Can one person bulk-export records?

How would it be tested? The specification says direct export of > N patients is refused [Open N]. That is the check for REQ-3114: bulk export by an individual must be disabled; bulk operations must run only through the quorum-approved Bulk Operation Workflow. Not yet. It is designed in the specification and not built in the pilot. Parts of it are explicitly marked as open in the specification.