Security

Verify it — don't take our word for it.

OLOBOLO holds evidence other companies may one day bring to auditors, courts and acquirers. That only works if our own security is real, boring and checkable. This page describes how the system is built and run — and links to the parts you can verify yourself, without an account and without trusting us.

Architecture

  • Metadata only. The chain never stores source code, prompts, spec text, review comments or test output — only hashes, references and metadata. What we do not hold cannot leak.
  • Append-only, enforced below the application. Chain entries are written through an insert-only database role; updates and deletes are refused by the database itself, not by application code promising to behave.
  • Immutable object storage. Exported evidence is stored with Object Lock in compliance mode, set at bucket creation — retention that neither we nor the provider's console can shorten.
  • EU infrastructure. Hosted on Scaleway (French-owned), regions Paris and Amsterdam, with managed PostgreSQL, KMS-held keys and provider-side audit trail.
  • Independent timestamping. The chain head is anchored daily via RFC 3161 at a European timestamping authority that is not our hosting provider — so tampering with storage cannot rewrite time.
  • Verification without an account. Anyone holding an exported chain can check its integrity with the open-source verifier — offline, against public documentation.

Operations

  • Two-factor authentication on every operator and provider account.
  • Least privilege. Access is scoped per role and per system; the provider's IAM and audit trail record administrative actions on the infrastructure.
  • Backups that must prove themselves. Backups are restore-tested quarterly, and a restore only counts as passed when chain verification passes against the restored data.

Development process

  • Spec-gated development. Nothing is built without an approved specification; the approval status is versioned and auditable.
  • We run on our own product. Every change to OLOBOLO is recorded in our own evidence chain — commits, reviews, test runs — since the commit that created the chain itself. Failures and exceptions are disclosed in the record, not smoothed over.
  • Standing security review. An internal security-watch process reviews the codebase, dependencies and agent setup on a schedule; findings are tracked with severities and an escalation path that has been exercised, not just documented.
  • License scan and SBOM per release. Each release carries a software bill of materials and a license scan; both are part of the release evidence.

What we don't have yet

We hold no SOC 2 report and no ISO 27001 certificate. We are an early-stage company, and pretending otherwise would be exactly the kind of claim this product exists to replace. What we do instead: everything above is verifiable rather than attested — the architecture is enforced in databases and storage settings, the development record is public to our customers in evidence form, and the verifier is open source. We will revisit formal attestation when a customer's own obligations require it, or when ten organizations pay for the service — whichever comes first. Until then, this page says what is true, and the chain shows it.

Verify without trusting us

Read the transcript
  • Verify without trusting us. No account. No network. Open source.
  • Export your chain. Run the open-source verifier — offline.
  • The verifier reads the export and reports the chain intact.
  • Now flip a single bit in the export…
  • The verifier fails the exact entry: one flipped bit, caught in milliseconds — offline.
  • OLOBOLO — evidence you can check, not claims to take on trust.