Concepts
OLOBOLO answers one question with evidence instead of anecdote: who — or what — wrote your code, and under which review? Five ideas carry the whole system.
The evidence chain
Section titled “The evidence chain”Every repository gets an append-only chain of entries. Each entry contains a payload hash, its predecessor’s hash and a timestamp — so the chain’s order and content are fixed the moment an entry is written. Changing or removing anything breaks every hash after it, visibly, for anyone holding an export. There is no admin backdoor to this: the database refuses updates and deletes at the trigger level, for every role including ours.
The five event types
Section titled “The five event types”| Event | Records |
|---|---|
change.authored |
A commit came into being — actor (human, or agent with tool + model), patch fingerprint, line counts |
spec.linked |
The change is tied to the specification that authorized it |
change.reviewed |
A decision about a change — reviewer identity, decision, time |
test.evidenced |
A CI run produced evidence — pass/fail counts, artifact hashes |
release.sealed |
A version is bound to a chain segment, forever |
The schema is frozen (schema_version: "0"); evolution only ever adds new
versions, and old entries verify against their own version — evidence
recorded today must still verify in ten years.
Metadata only — your code never leaves
Section titled “Metadata only — your code never leaves”No payload field can hold source code, prompts, spec text, review comments or test output. The collector hashes the actual patch on your machine and sends the fingerprint. When a buyer or auditor later samples the chain, you produce the referenced material from your own systems, hash it, and compare — the chain proves integrity, your archive holds content.
Disclosed exceptions
Section titled “Disclosed exceptions”Real development has gaps: a hotfix pushed past review, an agent change linked to its spec after the fact. OLOBOLO records these as disclosed exceptions rather than repairing them silently — an unbroken record that includes its own exceptions is stronger evidence than a spotless one, and every report shows them.
Seals and anchors
Section titled “Seals and anchors”A seal (release.sealed) binds a version to a chain segment: from
entry X to entry Y, hash Z — the unit that release evidence reports and
attestations are generated from. An anchor is an RFC 3161 timestamp
token from an independent European time-stamping authority, requested
daily and at every seal: it proves the chain head existed at a point in
time, on the authority of someone who is not us — and not our hosting
provider either. Anchoring status is always shown honestly: a missing
receipt renders as anchoring pending, never as silence.
Where trust actually sits
Section titled “Where trust actually sits”You are never asked to trust OLOBOLO’s word. The export is canonical
JSONL; the verifier is a zero-dependency tool anyone can
run or reimplement from the public format; the anchor
verifies with plain openssl. Our own development runs on this exact
machinery — the demo chain is our real history, from the first commit.