Federated ledger, spheres, tokens, wallets, bridges

C0922What may be written to the ledger, and what is never allowed on it?

No. The specification describes it, but the pilot does not include it. For reference, REQ-3001 (a top-priority requirement, all three tiers) says the ledger must store only: salted record commitments, consent tokens and metadata, audit batch roots, authority/transfer records, wallet and token state, node presence, alerts and tombstones. Patient content, names, national ids and raw clinical values must never be written. Check: a schema linter and a runtime chaincode check reject any field not on the allow-list; a red-team test injecting a name/CPF is refused.

C0923What is a sphere, and how does a clinic or network fit in one?

Each clinic or clinic network must be one sphere with its own ledger channel, membership registry and governance keys. That is REQ-3002, 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: two spheres cannot read each other's channel data except through bridge records.

C0924Does AuroraMed implement the token types ID, ROLE, CONS, GRANT, XFER, BRG-A/BRG-B, NODE, ALERT, BG and DELEG with the semantics in design 11.5, all non-transferable except through protocol operations. [Recommended: types from design 11.5; owner must confirm the final list]?

Designed, not built: there is no code for this in the pilot. REQ-3003 says the system must implement the token types ID, ROLE, CONS, GRANT, XFER, BRG-A/BRG-B, NODE, ALERT, BG and DELEG with the semantics in design 11.5, all non-transferable except through protocol operations. [Recommended: types from design 11.5; owner must confirm the final list]. Its acceptance check: attempt to transfer a token by holder is rejected; each type has chaincode tests.

C0925Does AuroraMed support mintable wallets of classes W-P, W-D, W-S, W-N, W-B, W-G with minting by quorum, identity binding, expiry and rate limits?

REQ-3004 is a top-priority requirement for all three tiers: the system must support mintable wallets of classes W-P, W-D, W-S, W-N, W-B, W-G with minting by quorum, identity binding, expiry and rate limits. This is on the design side of the line. Nothing in v0.2.0 does it. To verify it, the specification says mass-mint above threshold raises a Red alert and freezes minting.

C0926How many people would have to agree before a sensitive ledger action goes ahead?

The federated ledger, spheres, tokens, wallets, bridges part of the specification (REQ-3005) says sensitive ledger actions must require multi-key corroboration by a role-diverse policy; the numeric threshold is (still an open decision) (the design example is 2-of-{clinical lead, privacy officer, security officer}). No. The specification describes it, but the pilot does not include it. Acceptance check: the policy engine refuses execution with fewer/incorrect signers; the threshold value is a config parameter, not code. Parts of it are explicitly marked as open in the specification.

C0927How would two spheres be connected through a bridge?

How would it be tested? The specification says fault-injection tests: kill relayer mid-commit leaves state IN_DOUBT then resolved; token count per bridge always 2. That is the check for REQ-3006: bridges between spheres must use exactly two mirrored bridge tokens with history on both sides, two-phase commit with time locks and defined failure states. Not yet. It is designed in the specification and not built in the pilot.

C0928Would typing rhythm or location be used to judge a session's risk?

Designed, not built: there is no code for this in the pilot. For reference, REQ-3007 (a top-priority requirement, all three tiers) says session risk bands (0-3) may use keystroke cadence, location and timestamp; keystroke cadence must be a review flag only and never a sole lockout trigger. Check: simulated cadence anomaly alone creates a review item, not a lockout.

C0929How is a patient's consent signed and revoked on the ledger?

Consent tokens must be signed by the patient wallet (or delegate) over canonical bytes including the hash of the rendered text and must be revocable with immediate ledger effect. That is REQ-3008, 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: revocation blocks new access within the propagation target [Open seconds]; signature verification fails if text hash mismatched. Parts of it are explicitly marked as open in the specification.

C0930How are record fingerprints on the ledger prevented from revealing anything?

No. The specification describes it, but the pilot does not include it. REQ-3009 says record commitments must be H(salt‖digest) with per-record 128-bit+ random salts held off-ledger. Its acceptance check: dictionary attack test on low-entropy values fails without salt.

C0931How are patient pseudonyms built, and how can they be cut?

REQ-3010 is a top-priority requirement for all three tiers: patient pseudonyms must be HMAC(K_sphere, id‖r_patient) so that destroying r_patient severs linkage. Not yet. It is designed in the specification and not built in the pilot. To verify it, the specification says after erasure test, pseudonym cannot be recomputed from the id.

C0932How would cryptographic erasure of a patient's data work?

The federated ledger, spheres, tokens, wallets, bridges part of the specification (REQ-3011) says cryptographic erasure must destroy DEK, salts and r_patient by quorum, write a tombstone and verify undecryptability. Designed, not built: there is no code for this in the pilot. Acceptance check: post-erasure decrypt attempt fails and is logged.

C0933Does patient care wait for the ledger to be reachable?

How would it be tested? The specification says with ledger stopped, all clinical workflows still run; queue drains in order after restart. That is the check for REQ-3012: the ledger client must queue writes when the ledger is unreachable and append them in order on reconnect; care must not depend on ledger availability. This is on the design side of the line. Nothing in v0.2.0 does it.

C0934Could the ledger's signature methods be upgraded later?

No. The specification describes it, but the pilot does not include it. For reference, REQ-3013 (a high-priority requirement, the medium and large tiers) says signature algorithm identifiers must be carried in every ledger message to allow crypto agility including hybrid PQC. Check: a test message signed under a second suite validates.

C0935Which ledger technology is the baseline, and could it be replaced?

Ledger technology is baseline Hyperledger Fabric; the system must isolate the ledger behind a service interface so that a signed hash-chained log with threshold anchors can replace it for single-owner spheres. That is REQ-3014, a high-priority requirement for the medium and large tiers. Not yet. It is designed in the specification and not built in the pilot. Test in the specification: interface contract tests pass against both back ends.

C0936What is a home node and what does node presence do?

Designed, not built: there is no code for this in the pilot. REQ-3015 says home nodes and node presence tokens must provide liveness attestation and out-of-schedule flagging to all nodes. Its acceptance check: heartbeat loss produces an ALERT token within the configured window (still an open decision). Parts of it are explicitly marked as open in the specification.