Verification

The Public Profile

What is public, what is private, and what actually enforces the boundary. Every published organization has a profile at /o/<slug>.

The public surface

A published organization has a profile at /o/<slug> — for example, openbooks.fyi/o/demo-transparency. It requires no account, no login, and no relationship with the organization. A journalist, a member, an auditor, or an automated agent can read it and check it.

A supporting evidence view sits at /o/<slug>/evidence, and individual filings are addressable at /o/<slug>/filings/<id> and retrievable as JSON. Related public surfaces include the organization directory at /transparency/directory and each organization's verification page at /transparency/<slug>/verify, described in Verification.

What is public

The public surface is a projection of the ledger — assembled from entries, the same way a filing is (see Filings):

  • The ledger's head — its current sequence number, head hash, and entry count.
  • Ledger entries themselves, which is what makes the chain checkable by a stranger.
  • Filing history: what was drafted, what an officer advanced, and when.
  • Officer approvals — that a named officer approved, and when.
  • The nightly checkpoint for the ledger, where one has been recorded.

Public dates are rendered in UTC. This is not a detail: an organization in Honolulu publishing an entry late on the first of the month would otherwise appear, to a reader whose clock is elsewhere, to have published it on the previous month — a discrepancy that looks exactly like backdating to the one audience most likely to notice it.

What is not public

  • Internal memoranda and officer-only commentary.
  • Personal information about counterparties beyond what is already public record.
  • Organization settings, membership administration, and billing.
  • The working queue of items awaiting an officer's decision.

The line is drawn at what an outside reader has standing to see. A political committee's contributor disclosures are already public record under Hawaii Revised Statutes chapter 11, and republishing them in a checkable form adds no exposure. An officer's working notes are not public record, and publishing them would deter the candor that makes the record accurate in the first place.

What enforces the boundary

This is worth being exact about, because the intuitive answer is wrong.

The boundary is enforced in the application: a session gate on the private workspace, and allowlists at the point where public data is assembled. The public projection is built from a named set of fields, so a field that has not been deliberately published is not published. The check happens at the source rather than in the view layer, which matters because a view that filters is a view that can be bypassed by adding another view.

Row-level security policies are defined in the database and constrain direct access to it, but they are not what protects the public profile. The application reads with a service credential, which by design is not subject to those policies. Row-level security is a backstop against direct database access; it is defence in depth, not the mechanism. Describing it as the enforcement would point an auditor at the wrong control.

The embeddable badge

An organization can embed a trust badge on its own website with a script tag pointing at /embed/<slug>.js. It renders current figures drawn from the same public projection, isolated in a shadow root so the host page's styles cannot alter what it says, and refreshes periodically.

The badge is a pointer, not a proof. It reports what the profile reports; a reader who wants assurance should follow it to the profile and check the chain rather than trust a widget served on the organization's own page. That is the entire reason the badge links back.