Dual record copies
Do both custodians agree?
Live checks compare the same entry in the DataOrg and AuditOrg copies of the record. Missing entries or different digests are surfaced.
Detects disagreement between record copies.Grafinate Partners
Grafinity / The accountability layer for data and AI
Grafinity™
Don’t just log it.
Prove it.
Grafinity keeps an immutable record of who did what to your data, and when: across every person, system, AI agent and partner. It ties each action to an approved identity, has two independent organizations sign off on the record, and gives auditors evidence they can verify without trusting you or us. Others govern what AI may do; Grafinity proves what it did. A working multi-site proof of concept, built by Grafinate Partners.
Every action has an accountable identityNo one approves their own workEvidence that checks out without us
01 / Data flow
From data activity to recorded evidence.
Applications send events. GrafLock handles file intake. Both create traceable activity without placing the original content in the record.
Architecture
How data enters—and what comes out.
Select any stage to see what enters, what happens, and what comes next.
Event producersApplications & AI agents
Application events through REST bridges and NATS. AI writers require dual-control onboarding.
- What enters
- Audit events from applications, services, and approved AI writers.
- What happens
- Events are packaged and published through REST bridges or the NATS queue under an enrolled identity.
- What comes next
- Events travel to the writer’s bridge and are submitted to Grafinity for endorsement.
Content intakeFiles & object storage
GrafLock receives, hashes, scans, and classifies content. Original bytes stay outside the record.
- What enters
- File and object bytes from connected storage.
- What happens
- GrafLock hashes, scans, and classifies each object, recording every custody step as a signed event.
- What comes next
- Only hashes, classification, and custody events reach the record; the bytes stay in storage or containment.
Governance inputOperators & assessors
DataOrg proposes and operates. AuditOrg reviews findings and records attestations.
- What enters
- Access requests, assessment findings, and review decisions from people in both organizations.
- What happens
- DataOrg proposes; AuditOrg independently reviews and approves or denies.
- What comes next
- Decisions and attestations are recorded as part of the governance history.
Grafinity
Two-organization audit record
- Identity & scope validation
- DataOrg + AuditOrg endorsement
- Committed event history
- Local SQL read models
- GrafPass issuance & exports
Independent QMDB witnessCheckpoints, cosignatures & inclusion proofs
Portable evidenceReviewers & verifiers
Signed GrafPass bundles—evidence packages anyone can verify—carry event digests, record verdicts, and witness proofs.
- What enters
- A signed GrafPass assembled from committed events and proofs.
- What happens
- Reviewers verify the GrafPass offline against a trusted issuer key—no access to Grafinity required.
- What comes next
- Verified evidence supports audits, assessments, and third-party review.
Assessment outputsGRC tools & assessors
OSCAL, SDR and CPO JSON support machine-readable evidence exchange.
- What enters
- Record-derived checks and attested findings.
- What happens
- Exports are generated in machine-readable formats (OSCAL, SDR / CPO JSON) using versioned control mappings.
- What comes next
- Downstream GRC tools and assessors consume the exports as evidence inputs.
Optional event streamSecurity monitoring
Committed audit events can be forwarded to Splunk HEC for SIEM workflows.
- What enters
- Committed audit events from the record’s event stream.
- What happens
- The bridge forwards events to Splunk HEC as they commit.
- What comes next
- Security teams correlate recorded activity with the rest of their monitoring.
In the record
Identity, hashes, and history
Actor identity, content fingerprints, lineage, classification, outcomes, and governance decisions.
Outside the record
Your data stays in storage
Original files remain in object storage or containment. Read models and exported evidence live outside the record.
A hash proves a content match, not confidentiality. Metadata in the record is visible to participating peers; confidential fields require additional protection.
02 / Three-prong validation
Agreement is checked, not assumed.
Three complementary checks address different failure points: the record copies, the independent history, and the fast query model.
Committed event
Signed by an enrolled identity.
Endorsed by both organizations.
Independent witness
Is the history anchored?
The QMDB witness records checkpoints outside the record hosts. Organization cosigners rebuild from their own peers before signing.
Provides independent inclusion and checkpoint evidence.Verified read model
Does the query match the record?
SQL copies make queries fast. On-demand checks compare rows against the record; GrafPass proofs are retrieved live, not from SQL.
Detects changes to the application’s query copy.GrafPass™
Both organizations’ digests, a cross-organization verdict, and witness proofs.
No anchor, no GrafPass.Changing an entry undetected would require compromising both organizations’ copies of the record, the independent witness and its co-signed checkpoints, and enrolled identities, all at once. No single party, including us, can do it. Endorsement proves who recorded and approved an event—not that the event happened in the real world.
03 / Accountability
Every action has an identity. Every decision has a second signature.
DataOrg operates and proposes. AuditOrg reviews and approves. The network enforces the separation for people, services, and AI agents alike.
- 01 / Identity
Every action has an accountable identity
People, services, and AI agents write only under an approved, key-bound identity, inside the scope their groups allow. A certificate with a different key is refused until the change is approved.
In the demo: an agent’s first write is refused. AuditOrg approves it, and the same agent succeeds. An out-of-scope write is refused.
- 02 / Separation of duties
No one approves their own work
The operator cannot activate its own writers, attest its own assessments, or lift a containment the other organization imposed. The network enforces it—not a workflow tool.
In the demo: DataOrg tries to activate its own writer and is refused. AuditOrg revokes an agent; DataOrg cannot reinstate it.
- 03 / Evidence
Evidence that checks out without us
A GrafPass verifies offline against keys the reviewer pins. Deeper checks re-read the record and the independent witness.
In the demo: change one byte in a GrafPass and verification fails. Stop the witness and the issuer refuses to issue.
Each identity bound to one signing keyWrites checked against permitted scopeEither organization can revoke; only the revoker reinstatesAttestation bound to exact findings
04 / Portable evidence
A report your audience can verify.
GrafPass, the data passport, is a signed evidence package anyone can verify. It carries the record and its proofs beyond Grafinity, and each tier states exactly what it establishes—and what it needs.
Evidence issuance
Prove live. Anchor. Sign. Deliver.
Select any stage to see what enters, what happens, and what comes next.
01 / SelectSubject or event range
Use the query projection to identify the events to include.
- What enters
- A subject, system, or event range chosen by the requester.
- What happens
- The local query model identifies the candidate events to include.
- What comes next
- The selected events are re-proven against the record—SQL only selects, it never serves as evidence.
From the local read model
02 / ProveRe-read both peers
Retrieve each event live and compare both organizations’ digests.
- What enters
- The selected event identifiers.
- What happens
- Each event is retrieved live from both organizations’ peers and their digests are compared.
- What comes next
- Events with matching digests across both organizations proceed to anchoring.
DataOrg + AuditOrg /verify
03 / AnchorCheck witness proofs
Validate inclusion proofs and cosigned checkpoints locally.
- What enters
- The proven events and their block references.
- What happens
- Inclusion proofs and cosigned checkpoints are fetched from the independent witness and validated locally.
- What comes next
- Fully anchored events proceed to signing; missing proofs stop issuance.
QMDB /proof + /cosigned
04 / SignCanonical GrafPass
Sign the verified body with the issuer’s Ed25519 key.
- What enters
- The verified, anchored GrafPass body.
- What happens
- The body is canonicalized and signed with the issuer’s Ed25519 key.
- What comes next
- The signed GrafPass is packaged for delivery.
Issuer key trusted by reviewers
No anchor, no GrafPass. Missing witness proofs or checkpoints cause issuance to refuse, not to substitute cached SQL evidence. A quiet record can use a heartbeat to advance the proof.
05 / Deliver portable evidence
Self-verifying HTML
Review the signed bundle and verify its integrity offline with a trusted issuer key.
- What enters
- The signed GrafPass body.
- What happens
- The GrafPass is packaged as a self-contained HTML bundle with verification built in.
- What comes next
- A reviewer opens it anywhere and verifies integrity offline against the trusted issuer key.
Signed JSON
The same GrafPass body and signature, packaged for downstream pipelines.
- What enters
- The signed GrafPass body.
- What happens
- The identical body and signature are emitted as JSON.
- What comes next
- Downstream pipelines and tooling consume the evidence programmatically.
OSCAL & assessment exports
Record-derived checks and exact-digest attestation feed OSCAL, SDR / CPO JSON, KSI history, and reports.
- What enters
- Record-derived checks and attested findings.
- What happens
- Exports are generated through versioned control mappings with exact-digest attestation.
- What comes next
- Assessors and GRC tools use the exports as evidence inputs—not as certifications.
Self-verifying HTMLSigned JSONOSCAL exports
| Verification | What it establishes | What the reviewer needs |
|---|---|---|
| T1GrafPass integrityOffline | The signed bundle is authentic and unchanged since issuance. | The GrafPass + an issuer key the reviewer pins |
| T2Data matchOffline | The object’s bytes match the content hash in the GrafPass. | Your copy of the data object |
| T3Record re-checkConnected | The transactions exist in the record and carry both organizations’ endorsement. | Read access to the record |
| T4Witness proofConnected | Each transaction is included in the independent witness log under a co-signed checkpoint. | Witness keys the reviewer pins |
| T5OSCAL re-projectionExport verification | The export matches what the GrafPass projects; any changed field is identified. | The OSCAL export + its GrafPass |
The open verifier has no dependencies and runs without us. OSCAL and FedRAMP-format outputs are evidence for an assessment package—not a certification or a determination of compliance. Current mappings cover 11 NIST SP 800-171 r2 controls and 17 FedRAMP Rev5 Moderate controls as starter mappings.
05 / Where it fits
Others govern what AI may do. Grafinity proves what it did.
Every serious platform has audit trails, identity, and governance. The question that separates Grafinity: who, besides the vendor and you, can check the record?
| Category | What they do well | Where Grafinity fits |
|---|---|---|
| Runtime AI controlServiceNow AI Control Tower, AI Passport | Discovery, governance, and runtime control of agents: what each agent may do, with a kill switch. | After the fact: two-party evidence of what agents did and which approvals were given.“They decide what an agent may do. Grafinity proves what it did.” |
| AI governance suitesIBM watsonx.governance, Credo AI | AI inventory, risk, policy, regulatory mapping, and monitoring across the model lifecycle. | A verification layer under their records—not a replacement for the suite.“A policy says what should happen. Grafinity proves what did.” |
| Data protectionMicrosoft Purview | Discovery, classification, protection, and compliance for data and supported AI apps. | Evidence of custody and decisions across organizations, alongside data protection.“Purview protects the data. Grafinity proves what happened to it.” |
| GRC and privacyOneTrust | GRC, privacy, and AI risk workflows. | Feeds verifiable evidence into the workflow you already run.“Keep your GRC process. Make its evidence verifiable.” |
| Compliance automationVanta, Drata, Paramify | Evidence collection through integrations; FedRAMP 20x and OSCAL packaging. | Their evidence is gathered and attested by the provider. Grafinity’s is endorsed by a second party and verifiable by the assessor—and OSCAL lets us feed them.“They collect your evidence. Grafinity makes it checkable.” |
| Tamper-evident databasesimmudb, Azure SQL ledger | Proof that one operator’s database was not altered. | Grafinity requires two organizations and an independent witness to agree.“Tamper-evident to whom? One operator can’t vouch for itself.” |
Grafinity does not do AI inventory, model risk, bias testing, or runtime control of agents. It is the evidence layer underneath the tools that do—their control, our proof.
06 / Who it serves
Where a record must satisfy someone outside the company.
In each market a regulator sets the evidence bar and a second party can sign as AuditOrg. Accountable AI agents are the opening story in every one.
FedRAMP cloud providers & 3PAOs
Grafinity exports the FedRAMP Security Decision Record, OSCAL documents, and 20x Key Security Indicator history—evidence for the package, which the assessor can re-derive.
Second party: the 3PAO, or the provider’s independent security team.
Financial services
A complete, time-stamped trail of every change and who made it, endorsed by a second party. Regulators increasingly ask firms to track and supervise what AI agents do.
Second party: the compliance function, or a designated third party.
Defense contractors
The NIST SP 800-171 r2 mapping behind CMMC Level 2 is built, so self-assessments can rest on dual-endorsed records. The C3PAO makes the determination.
Second party: a C3PAO, or the contractor’s independent security team.
Life sciences
Sponsor and CRO are two parties by nature. Time-stamped, attributable trails for regulated records and the AI used in trials and manufacturing.
Second party: the sponsor’s quality assurance, or the CRO.
Healthcare delivery
Attributable trails for systems and AI agents that touch patient data. Content stays in its storage; only hashes and opaque identifiers enter the record, so no patient information is recorded there.
Second party: the compliance or privacy office, or a business associate.
Media & entertainment
Provenance and chain of custody: who registered an asset, when, and that it is unchanged since—a record that survives when file metadata is stripped.
Second party: a distributor, guild, rights society, or registry.
Grafinity supplies evidence; assessors, auditors, and regulators make determinations. It provides provenance and chain of custody, not proof of authorship or copyright, and regulated life-sciences use requires a validation package first.
07 / System behavior
When conditions change, evidence stays explicit.
Delivery failures, mismatched records, and unavailable proofs are distinct states—not silently treated as verified results.
Queue or transient delivery failure
Events spool locally when the queue is unavailable. Transient submissions retry with backoff; acknowledgement follows commit to the record, not initial receipt.
Invalid or unauthorized event
The network’s rules reject the event. Invalid events move to a dead-letter queue rather than becoming committed evidence.
Witness unavailable or parties disagree
A witness outage does not stop writes to the record, but anchored GrafPasses are withheld. Disagreement halts the witness or stops a cosigner until an operator resolves it.
Query copy altered or lost
Integrity checks flag divergence from the record. The affected row can be re-projected, or the query model rebuilt from committed blocks.
08 / Roadmap
Prototype → MVP → production.
The prototype is complete and running across seven sites. The MVP phase hardens and measures it; production scales it through certified partners.
- Phase 0 · Complete
Prototype
- Two-organization network across seven sites
- Rules engine v5.2 with dual-control identities
- Witness, GrafPass and the open verifier
- NIST 800-171 r2 and FedRAMP Rev5 assessments; OSCAL and SDR exports
- SDKs in four languages; three consoles; test suite
- GrafLock vault v0.4.0 with the S3 endpoint
- Phase 1 · Months 0–9
MVP
- FIPS-validated cryptography, witness included; HSM-rooted keys; encryption at rest
- Console login and role-based access tied to roles in the record
- Witness signature on every checkpoint; versioned regulatory profiles
- Published benchmarks at 3- and 5-site topologies
- Independent security test; rules-engine audit
- GrafLock vault journal anchored to the Grafinity witness
- Design partners live; 3PAO review; SOC 2 Type I
- Phase 2 · Months 9–30
Production
- Certified AuditOrg partner program; one profile from 3 to 30+ sites
- Profiles for finance, life sciences, healthcare and media
- Redactable GrafPasses; EU AI Act Article 12 evidence pack
- SIEM integrations: Splunk, Sentinel, Chronicle
- 3PAO acceptance in a live assessment; SOC 2 Type II
The current demo kit uses software keys and does not provide a validated cryptographic module or encryption at rest. Demo consoles rely on network access; console login and role-based access are MVP scope. Scale to billions of events and 30+ sites is designed, not yet benchmarked.
GrafLock intake interface
Development view
A focused conversation
Bring us your hardest audit request.
We’ll show you a record failing verification—then walk your request through the evidence.