This reference is written for regulators, bank examiners, and auditors who are reviewing a Chandra-backed audit trail. No prior knowledge of Chandra is required. Every term is defined. Every verification step is explicit.
For examiner inquiries that cannot be resolved through this document, contact General Reasoning directly: inquiries@genreason.com. We respond to examiner inquiries within one business day.
Chandra is an open protocol for producing append-only, cryptographically sealed, attributed audit records. It was designed by General Reasoning, Inc. and is published under the MIT License.
The core principle: every act — every human decision, every automated action, every agent operation — produces an audit record at the moment it occurs. That record is immutable. It is linked to its predecessor by a cryptographic hash. The chain of records cannot be altered without breaking the hash link, which is immediately detectable.
The result is an audit trail that is not a retrospective reconstruction. It is the simultaneous product of the work itself. There is no gap between act and record because the record is the act.
Chandra is used by organizations subject to regulatory oversight to produce compliance-grade audit trails for operational, financial, and AI-governed processes. It is also used by auditors as the governed work paper infrastructure for attestation engagements.
In Chandra, the atomic audit record is called a context unit (CU). Every CU contains:
Every CU references its predecessor by id and by hash. The chain is verified by computing the hash of each CU and comparing it to the value stored in the successor's prev_hash field. A mismatch at any point in the chain indicates tampering or corruption. A broken chain halts new appends — no new records can be added to a compromised chain.
Each auditable entity — a ledger entry, a user account, a policy record, an AI agent action — has its own independent chain called a spoke. Spokes are independent. A compromise of one spoke does not affect others.
A GABA cert (Governed AI Boundary Attestation) is the credential that attests a deployment's governance posture. It is issued by General Reasoning through gr-identity, the identity and governance platform that connects to chandrahub.net.
A GABA cert contains:
The organization should be able to provide their GABA cert id from their gr-identity console. It is a UUID in standard format.
Send a GET request to the chandrahub verification API with the cert id. No authentication required for examiner verification calls.
The response confirms: cert status (active, revoked, superseded), issuing authority, compliance profile, issuance timestamp, and the CU id of the issuance record. A revoked cert indicates the deployment's governance posture has changed and a new cert should be requested.
The issuance_cu_id in the cert response links to the context unit that authorized the cert. This CU is on the organization's Chandra chain and is independently verifiable. See Section 5 for how to read a CU.
Chain integrity verification confirms that a spoke's audit trail has not been altered since the records were written. This is the primary verification act for examining a Chandra-backed audit trail.
The spoke address is the unique identifier for the auditable entity under examination. For a specific record (e.g. a ledger entry, a user account), the organization can provide the spoke address from their gr-identity console or from the chandra_record_id column in their database.
Returns: genesis CU id, current tail CU id, CU count, last append timestamp, integrity status (intact / compromised / gap detected), and any integrity alerts.
intact — chain is complete, hashes verify, no gaps. compromised — hash mismatch detected at a specific CU. gap_detected — one or more CUs are missing from the sequence. Any status other than intact requires escalation to General Reasoning.
Returns the complete ordered sequence of CU ids for this spoke, from genesis to current tail. Use this to sample specific records in the chain for detailed examination.
A context unit is the individual audit record. Examiners may wish to read specific CUs to confirm what occurred, who authorized it, and when.
cu_id — the unique identifier for this record. Cite this id in examination findings when referencing a specific audit event.
subject_id — the entity this record belongs to. All CUs with the same subject_id form one spoke — the complete audit trail for one entity.
predecessor_id / prev_hash — the chain link. predecessor_id is the id of the prior record. prev_hash is the cryptographic hash of that prior record. Verify by computing the hash of the predecessor CU and comparing to prev_hash.
published_at — Unix timestamp. Immutable. Cannot be backdated or edited. The timestamp is set server-side at the moment the record is written.
human_author — the identity of the human principal responsible for this act. Required on every CU. Anonymous records are rejected at the protocol level.
agent_id — the identity of any automated agent involved in this act. Null if the act was performed entirely by a human.
event_type — a structured label describing what occurred. Set by the application at record creation time.
artifact — the payload. The actual content of the event. Format is defined by the application and declared at hub registration time.
When Chandra is used as the governed work paper infrastructure for an attestation engagement, the engagement produces a structured audit record: an engagement spoke containing every audit act from acceptance through opinion issuance.
Every Chandra-based engagement has an engagement id. The engagement spoke contains, in chronological order: acceptance CU, planning CUs, fieldwork CUs (one per audit procedure performed), finding CUs (one per identified exception or observation), and the opinion CU as the terminal record.
Returns: engagement type, auditee organization, applicable standard, scope declaration, status, acceptance timestamp, acceptance CU id, opinion CU id (if opinion has been issued), and CU count.
The opinion CU artifact contains the full text of the audit opinion, the name and credential of the issuing auditor, and references to the specific finding CUs that support the opinion. Each finding CU references the evidence CUs — the specific records examined — that support the finding.
The opinion CU artifact lists finding_cu_ids — the specific findings that informed the opinion.
Each finding CU artifact contains the finding type, severity, description, and evidence_cu_ids — the specific records examined as evidence for that finding.
Each evidence CU is a record in the auditee's chain. It is immutable. It was written at the time of the act it records. The hash chain confirms it has not been altered since.
General Reasoning, Inc. is the issuing authority for GABA certs and the operator of chandrahub.net. Our compliance posture is the terminal trust anchor for the Chandra ecosystem.
Current compliance status and scope declaration are published at chandrahub.net/docs/compliance. That page is updated whenever our compliance status changes and carries a CU id confirming the update has not been altered.
For examiner inquiries requiring confirmation of our compliance posture, contact us directly. We provide examiner confirmation letters on request.
Chandra uses specific terminology. The following table maps Chandra terms to standard audit vocabulary.
General Reasoning, Inc. welcomes examiner inquiries. We do not require advance notice and we respond within one business day.
Examiner inquiries: inquiries@genreason.com
Urgent matters: Note "EXAMINER — URGENT" in the subject line for same-day response.
Mailing address: General Reasoning, Inc., Birmingham, Alabama, United States
We provide on request: confirmation letters for examiner files, compliance posture documentation, engagement record exports in standard formats, and technical briefings for examination teams unfamiliar with Chandra.