Skip to content
Gungner docs

Canonical objects and evidence

The canonical objects

Section titled “The canonical objects”

Every surface — REST, the event log, and the MCP server — returns the same shapes. Today, those are:

  • Subject — the tenant-scoped identity anchor described on the Subject ID page.
  • Identity event — a record of an identity-verification event, such as a BankID login or signing.
  • Person profile — names, protection status (for example, a protected identity / sekretessmarkering flag), addresses, and folkbokföring status.
  • Company profile — org.nr, name, legal form, status, registered address, and today a nested reference to the latest annual report. Full structured financials parsing is planned but not shipped yet — don’t expect a separate “financials” object on the wire until that lands.
  • Officers and signatories — who can act for a company.
  • Beneficial owners — who ultimately owns or controls a company.
  • Engagements — a person’s directorships and roles across companies.
  • Monitoring subscription — an active, suspended, or ended subscription that keeps a subject’s data fresh over time. See Monitoring subscriptions for the full picture.
  • Screening check and screening candidate — the result of a sanctions/PEP/adverse-media screening run, and any candidate match within it. See Screening.

Evidence

Section titled “Evidence”

Every field group on every canonical object carries its own evidence — not the object as a whole, but each group of fields within it. A company profile’s registry fields (name, status, address) and its tax fields, for example, can come from different sources, so each group names its own evidence independently.

An evidence bundle has these fields:

Field Meaning
source Which upstream produced this field group (for example, the Swedish company register or the Swedish person register).
source_timestamp When the source itself says the value was last true or last changed.
retrieved_at When Gungner fetched it.
call_ref Gungner’s own record of the call that produced this field group.
transaction_ref A deprecated alias of call_ref, currently kept equal to it during a transition period — prefer call_ref in new integrations.
upstream_ref The upstream’s own identifier for the exchange, when it provided one. Nullable — not every upstream gives one.
digest A hash of the raw upstream response, so a disputed value can be checked by re-fetching and comparing hashes. Nullable.
schema_version The version of the raw wire format used to parse this field group. Nullable.

call_ref is the one to hold onto. If a value ever looks wrong, Gungner can re-fetch using that reference and compare the resulting digest against what was originally recorded — without needing to have retained the original raw response, which may contain personal data.

Why this matters

Section titled “Why this matters”

Every fact Gungner returns is traceable back to exactly when and how it was obtained. That matters for compliance, and it matters the day someone asks “why does your data say X” and you need a real answer rather than a shrug.

Next

Section titled “Next”