Your organization uses a system that produces a Chandra audit trail. This guide explains what that trail contains, how examiners access it, and what you need to do when an examiner requests audit evidence.
Every write operation your application makes produces a context unit (CU) — an immutable, attributed, timestamped record of what occurred. The CU records: what entity was affected, what changed, who authorized the change, and exactly when it happened.
Your audit trail is organized as follows. Each individual record in your application — a ledger entry, a user account, a transaction — has its own spoke: an ordered chain of every CU ever written for that record. Every spoke for a given table type is grouped into a hub. All hubs for your organization form your domain. Your domain is connected to chandrahub.net as the forest authority.
The examiner will specify records by date range, entity type, or specific identifiers. Your application should be able to map these to specific record ids.
Your database carries a chandra_record_id column on each auditable table. This is the spoke address that connects each record to its Chandra audit trail.
The examiner can then independently verify the chain integrity and read any specific CUs through chandrahub.net without requiring access to your application or database.
Your GABA cert id is available in the gr-identity console under Compliance › GABA Cert Manager. The examiner can verify its current status independently through chandrahub.net.
Your Chandra audit trail is retained according to the retention policy declared in your GABA deployment template. The following are the minimum retention requirements for common frameworks.
General Reasoning retains all CU data for the period declared in your deployment agreement. Retention extensions are available on request before the retention period expires.
When your Chandra integration was verified by General Reasoning, a Cleared-to-Operate cert was issued. This cert is the compliance instrument that confirms your integration was tested, verified, and found to be producing valid CU records across all registered tables.
The cert is available in the gr-identity console under Compliance › Cleared-to-Operate Cert. It can be downloaded and provided to examiners as evidence of integration compliance.
A new cert is issued whenever your integration changes — new tables registered, existing tables retired, hub token rotated. The supersession chain is maintained and available to examiners on request.
The gr-identity Integration Manager provides a Spoke Health view for each registered table. This view shows: CU count per spoke, last CU timestamp, chain integrity status, and any alerts. Review this view periodically and before any examination period to confirm your audit trail is intact.
If you observe any integrity alerts, contact General Reasoning immediately. Do not attempt to remediate chain integrity issues independently.