The activity record
The shape of the one record the Explorer writes per lookup or verification, and where it lives.
Every lookup or verification the Explorer performs against the oracle produces one activity record. The record is written to Postgres and indexed for search.
Fields
| Field | Meaning |
|---|---|
kind | Which operation produced the record: verify, status, or resolve. |
subject_did | The DID the record is about. |
credential_id | The credential's identifier, when the operation concerned one. |
cred_type | The credential's type, for example KYCVerified. |
issuer | The DID or address of the credential's issuer. |
status | The oracle's answer, valid or revoked, when the operation returned one. |
source_chain | Which chain the oracle read to answer: eIDChain, Ethereum, or Hyperledger Fabric. |
block_hash | Reserved for the block the answer was read from; see below. |
outcome | Whether the call itself succeeded: ok or error. |
error_msg | The error, when outcome is error. |
issued_at | The attestation's issue time, from the oracle's signed response. |
expires_at | The attestation's expiry time, from the oracle's signed response. |
signature | The oracle's signature over the attestation. |
raw | The full oracle response, kept for the record's detail view. |
created_at | When the Explorer wrote the record. |
The storage split
Postgres is the source of truth. Elasticsearch is a rebuildable view of it, not a second source. Writes go to Postgres first; only after a record is committed there does the Explorer index it into Elasticsearch, and that indexing step is best effort. If the Elasticsearch index drifts or is lost, it is rebuilt from Postgres. The reverse never happens: nothing is recovered from Elasticsearch into Postgres, and no data a visitor sees lives only in the index.
Two honesty notes
block_hash is reserved and is currently always empty. The oracle's signed
attestation carries no block hash, so nothing feeds this column yet. This
is recorded as a known gap in the Explorer's own design document, not an
oversight discovered here.
A record with outcome of error is still a record. The activity feed
shows failed lookups alongside successful ones, and this is deliberate: a
lookup that failed to resolve, or a verification that came back invalid, is
part of the network's history as much as a clean success is.