Priya Raghavan’s final audit question was about proof. She had verified the residency model, tested the clinical boundary enforcement, and examined the sensor fusion architecture. Now she wanted the receipts. Every system she audits claims to log everything. Most systems log some things, inconsistently, in formats that are difficult to query and impossible to verify for tampering. Priya wanted to see the audit trail, and she wanted to know whether the audit trail could be trusted.
She pulled up a test account’s activity log from the previous day. The system returned a chronological record of every action taken on the person’s behalf, every data access event, every consent change, every escalation decision. The log was readable. The log was complete. And each entry carried a cryptographic signature that chained it to the entry before.
What is logged#
The audit trail records seven categories of system activity. Every query the person makes to the system. Every MoC activation, meaning every time the system reads a section of the person’s context to serve a request. Every infrastructure agent invocation, meaning every time a behind-the-scenes agent performs work such as scheduling, data retrieval, or preference matching. Every SLM inference, meaning every time a model produces an output. Every external data sharing event, meaning every time data crosses the membrane to an outside party. Every consent change, meaning every time the person grants, modifies, or revokes a permission. Every escalation decision, meaning every time the system decides to surface a decision to the person rather than handling it autonomously.
The volume is substantial. A typical day produces between 200 and 800 log entries depending on the person’s engagement level and the number of background processes running. The wearable data fusion alone generates log entries for each sensor reading window. The health concierge’s morning vital signs check produces entries for the query, the MoC activation, the SLM inference, and any resulting alerts. A buying agent negotiation with a vendor generates entries for the outbound query, the membrane context package, the vendor’s response, and the agent’s decision.
The question is not whether logging at this granularity is feasible. Edge hardware with the storage capacity described in Series 06 and Series 09 can hold years of audit logs at this density. The question is whether the logs are trustworthy.
Cryptographic integrity#
Each log entry is signed with a hash-based message authentication code derived from the entry’s content and the previous entry’s signature. The chain is append-only. Inserting, deleting, or modifying an entry in the middle of the chain breaks the signature verification for every subsequent entry. Tampering is detectable by any party that can verify the chain, which includes the person, her designated auditors, and regulators with lawful access.
The signing key is held by the Local Pane’s secure enclave for Zone 1-captured entries and by the Community Pane’s hardware security module for Zone 2-captured entries. The system software in either zone cannot access the signing keys directly. It submits log entries to the secure enclave or HSM for signing through a hardware-protected interface. This means that even if the system software were compromised, the attacker could add false entries to the chain (they would be signed by the legitimate key) but could not modify or delete existing entries without detection.
The architecture does not prevent a sophisticated attacker from appending false entries. It prevents retroactive falsification. Priya noted this distinction in her audit: the threat model covers data integrity (was this record modified after creation?) but not data authenticity (was this record truthful when created?). A system that logs “consent granted” when consent was not actually granted would produce a cryptographically valid but factually false chain. The defense against this is that consent changes require the person’s explicit action through the user interface, which is itself logged and auditable. Fabricating a false consent grant requires compromising both the audit system and the user interface, which is a substantially harder attack.
The three-zone audit trail#
The audit trail distributes across the zones present in a subscriber’s deployment path. For subscribers with a Local Pane, Zone 1 logs all local inference events, consent checks, and Privacy Filter decisions made on the device. For subscribers in regions with a Community Pane, Zone 2 logs all cross-domain reasoning, MoC access events, and external agent interactions handled at the regional node. Zone 3 (the cloud reasoning layer) logs the events from queries that route to Zone 3: for full-stack subscribers, this is a subset of events covering deep-reasoning queries that exceed Zone 2’s capacity; for Zone 2 + Zone 3 subscribers, similarly a subset; for Zone 3-only subscribers, the Zone 3 log is the full audit trail because every query routes to Zone 3. Zone 3 also stores anonymized audit aggregates for compliance reporting and population-level analytics across the entire subscriber base, regardless of deployment path.
The zone split mirrors the compute split. The decisions made in Zone 1 are logged where they are made. The decisions made in Zone 2 are logged where they are made. The decisions made in Zone 3 are logged in Zone 3, with the same cryptographic integrity guarantees as the other zones. For full-stack subscribers, a subpoena served on Zone 3 would produce only the events for queries that routed to Zone 3 and the anonymized aggregates; subpoenas served on the subscriber’s specific Zone 1 device or Zone 2 regional node would be required to produce the full audit trail. For Zone 3-only subscribers, a subpoena served on Zone 3 produces the subscriber’s full identifiable audit trail under the DPA’s audit rights and lawful process provisions. The architecture does not hide this fact. It is a direct consequence of the deployment path.
The zones cross-reference each other through correlation IDs that allow an audit query to trace an interaction across zones without copying records. A query that starts in Zone 1 (the subscriber asked a question), traversed Zone 2 (the H-layer delegated to a Zone 2 SLM), and reached Zone 3 (for the deep reasoning portion) produces three audit entries linked by a correlation ID. The full trace is reconstructed by joining the entries across zones, which requires lawful access to each zone’s records.
The person’s audit interface#
The audit trail is not designed for Priya. It is designed for the person. The raw log, with its cryptographic signatures and machine-readable event codes, is available for formal audit. The person sees a translated version.
The translation converts machine events into natural language. The raw log entry for a health concierge blood pressure check contains fields for the query type, the MoC layers accessed, the SLM model invoked, the inference result, the confidence score, the action taken, and the timestamp. The person sees: “Your health concierge checked your blood pressure trend at 8:00am. It found your morning readings have been elevated this week. It recommended mentioning this to Dr. Patel. You agreed at 9:15am.”
The translation is not a summary. It is a faithful rendering of the log entry in language the person can understand. Every element in the natural language version maps to a specific field in the raw log. The person can toggle between the readable version and the raw log at any time. Most people never toggle. The option exists for those who want it, and for Priya, who always wants it.
The person can ask the audit interface temporal questions. “Show me everything the system did on my behalf yesterday.” “Show me every time my health data was shared with anyone in the last month.” “Show me every time the system made a decision without asking me.” Each query produces a filtered view of the same underlying log. The filters are defined at the application layer, but the data they filter is the same cryptographically chained log.
Priya tested the temporal queries against the raw log by comparing counts. The “everything yesterday” query returned 347 entries. She manually counted 347 entries in the raw log for that date range. The “health data shared” query returned 4 entries, each corresponding to a FHIR write-back or a membrane transit event. The “decisions without asking” query returned 23 entries, each corresponding to an action taken at BOUNDED_DELEGATION or higher autonomy level. The counts matched. The filters return exactly what they claim to return.
Regulatory compliance#
The audit trail was designed against three regulatory frameworks simultaneously. HIPAA requires covered entities and business associates to maintain audit controls that record and examine activity in information systems containing protected health information. The HIPAA Security Rule specifies that these controls must track access to electronic protected health information. BlueMirror’s audit trail exceeds the requirement because it tracks not only access but also the purpose of access, the result of the access, and the person’s subsequent consent action.
State privacy laws, particularly the California Consumer Privacy Act and its successors, require that consumers be able to know what personal information is collected, how it is used, and to whom it is disclosed. The audit trail provides all three. The data map from BMT-07.01 shows the “what.” The audit trail shows the “how” and the “to whom.”
The GDPR’s data subject access request provisions require that the data controller provide a copy of personal data being processed, the purposes of processing, the recipients of the data, and the retention period. The audit trail, combined with the data map, satisfies a GDPR DSAR fully. The export function produces a structured file containing every log entry, every data sharing event, every consent record, and every active permission. The export format is machine-readable (JSON with a documented schema) and human-readable (the same natural language translation the person sees in the interface).
The architecture was designed against the GDPR because it is the strictest of the three frameworks. Meeting GDPR automatically satisfies HIPAA audit controls and CCPA disclosure requirements. Priya confirmed this in her regulatory mapping, which she performs for every system she audits: the BlueMirror audit trail meets all three frameworks from a single implementation. Most systems she audits require separate compliance layers for each regulatory framework, which creates complexity, inconsistency, and gaps.
Retention and deletion#
Audit logs are retained for seven years from creation. The retention period aligns with the longest applicable regulatory requirement (HIPAA requires six years for policies and procedures; the seven-year period provides margin). After seven years, log entries are purged in batch, with a final integrity verification of the chain segment being purged.
The person can request deletion of her personal data at any time under GDPR’s right to erasure or CCPA’s right to delete. The deletion applies to MoC data, preference models, and personal context. It does not apply to the audit trail itself for entries that the system is required to retain under HIPAA or other legal obligations. This creates a tension that the architecture handles explicitly: the person’s data is deleted, but the record that the data once existed and was subsequently deleted is retained. The audit trail entry reads: “Personal data deleted per user request on [date]. Prior audit entries retained per regulatory retention requirement.”
Priya flagged this tension as correctly handled. The alternative, deleting the audit trail when the person requests data deletion, would undermine the regulatory compliance that the audit trail exists to serve. A system that deletes its proof of compliance when asked is a system that cannot prove compliance. The person’s right to deletion is honored for her data. The system’s obligation to prove it handled her data correctly is honored by the audit trail’s retention. The two obligations coexist because they apply to different things.
What the audit trail does not cover#
The audit trail records what the system did. It does not record what the system considered and rejected. If the health concierge evaluated three possible alert messages and selected the one with the clearest clinical language, the audit trail records the selected message. It does not record the two rejected alternatives. This is a design choice, not a limitation. Recording every intermediate inference step would increase log volume by an order of magnitude and would produce a log that is forensically interesting but operationally unusable.
The audit trail also does not cover actions the person takes outside the system. If the person calls Dr. Patel and discusses the blood pressure trend the system surfaced, that conversation is not logged. The system knows it surfaced the trend. It does not know whether the person acted on it. Outcome tracking, described in Series 08, addresses this gap partially through feedback loops, but the audit trail itself is bounded to system activity.
Priya closed her audit with a final observation. The audit trail is the mechanism that converts privacy promises into verifiable facts. Any company can claim privacy. Any company can write a privacy policy. The audit trail is the answer to the question that regulators, investors, and the person herself will eventually ask: can you prove it?
Cross-References#
BMT-03.04 Sandbox Audit Trails. The audit logging for sandboxed agent interactions, which feeds into the main audit trail described here.
BMT-04.03 Contextual Consent. The consent architecture whose changes are tracked as a primary audit category.
BMT-05.05 Consent Architecture Audit. The consent-specific audit mechanisms that integrate with the broader audit trail.
Technical Appendix BMT-07.04-A is available to partners and investors at partners.bluemirror.tech.