Connect a published SQLite extract

If your institution publishes a read-only SQLite extract rather than an API, Registry Evidence can answer from that file without connecting to your database. You create a new project here, not the standalone one from your first assertion, prove it over synthetic extracts, and bind a file.

Outcome: A SQLite-extract Evidence project passing 13 fixture cases.
Time: About 15 minutes
Level: Offline authoring with synthetic data
Prerequisites: The Evidence component for rstack, v0.45.0 or laterA shell and an editor

Use v0.45.0 or later of the Evidence component, installed as in your first Evidence assertion. It is the first release that reads Adapter packs, and the 0.44.0 tools cannot read this project form.

Create the SQLite starter

init writes a starter project whose one Source reads an extract:

rstack evidence init registry-status \
  --transport sqlite-extract \
  --profile local

Created an editable SQLite-extract authoring project in registry-status
  README: registry-status/README.md (what each file holds, and what comes next)
  project: registry-status/evidence.yaml
  functions: registry-status/functions
  adapter packs: registry-status/adapter-packs
  target: registry-status/local-target.yaml
  authority: registry-status/dev-authority.yaml
  fixtures: registry-status/fixtures
  keys: registry-status/.generated/secrets (owner-only, disposable, and unbound)
Next: run `evidencectl check registry-status` and `evidencectl test registry-status` to prove the synthetic starter, then edit its source, statement, schemas, derivation, and fixtures together.
A normalized synthetic Source, AssertionDefinition, and local target were generated. No production extract or deployment bundle was generated.

Keep the disposable keys in .generated/ out of version control.

Read the extract binding

Work from the project directory:

cd registry-status

The record-status Source binds the reviewed SQLite pack route and passes only its authorized selector:

sources:
  record-status:
    acquisitionPosture: record-transformed
    connection: starter-source
    inputs:
      recordReference:
        selector:
          field: record-reference
          profile: record-reference
          role: subject
    pack:
      id: starter-source
      version: '1'
    route: lookup

The pack’s starter-source endpoint names the logical extract profile record-status. Its sqliteExtract.statement pins one fixed statement, while the target supplies the file path:

SELECT qualifying_record_count
FROM records
WHERE reference = :record_reference
ORDER BY record_id;

The route binds recordReference to the named SQL parameter record_reference. A caller’s value never becomes statement text. The pack pins its statement, schemas and extraction script by digest. When you review an asset change, evidencectl check refuses the stale pin and prints the file’s new digest; copy it into the pack document.

Read what the answer means

The record-status assertion definition carries the identifiers a relying party reads:

outputs:
  satisfied:
    concept: urn:example:concept:record-status:v1
    type: boolean
purpose: record-status-check
question: Does the selected synthetic record satisfy the reviewed condition?
representations:
  - signed-jws
semantics:
  evidenceType: urn:example:evidence-type:record-status:v1
  kind: criterion
  referenceFrameworks:
    - urn:example:framework:record-status:v1
  requirement: urn:example:requirement:record-status:v1

Replace every urn:example: identifier, the purpose, and the question with your institution’s reviewed ones, keeping one boolean output from one Source. How Evidence works explains each part.

Prove the starter

rstack evidence check . --target local-target.yaml --deny-warnings
rstack evidence test . --target local-target.yaml --deny-warnings

Evidence project check: complete
Project: .
Target: local-target.yaml
0 errors, 0 warnings in 1 file
PASS: check
PASS: fixtures/record-status.yaml (13 cases)
2 passed, 0 failed (13 cases evaluated)
Proof: offline synthetic fixture evaluation; no live dependency readiness was checked

Each case writes a read-only synthetic extract, and the evidence binary runs the fixed statement against it and evaluates the answer. Fixtures are how you run this project locally, because rstack evidence dev start refuses a SQLite Source: local serving has no way to bind an extract file. A warning or error names the file and key to correct.

Adapt it to your extract

Change these together, then rerun both commands:

In adapter-packs/starter-source/queries/record-status.sql, select only the facts the assertion needs from your table, keeping every caller value in a named parameter.
In the pack, update the endpoint columns and parameters, route bindings, schemas and extraction script together. Preserve finite limits, including maximumExtractAgeSeconds, and refresh each changed asset’s digest. In evidence.yaml, keep the Source inputs consistent with its selector profile.
In functions/derive-record-status.rhai, update the derivation for the private facts the pack returns.
In dev-authority.yaml, update the grant for any identifier you renamed.
In fixtures/record-status.yaml, replace the rows with invented ones and keep the refusal cases that still apply.

Bind an extract file

The target, not the project, says which file an extract profile reads. init already bound record-status to a placeholder path in local-target.yaml, because a target must bind every extract profile its Sources use. Point the binding at the file your export tooling published, with <extract-file> replaced by its name:

extracts:
  record-status:
    path: extracts/record-status.sqlite
    path: /var/lib/registry-evidence/extracts/<extract-file>.sqlite

Check the target again:

rstack evidence check . --target local-target.yaml --deny-warnings

Evidence project check: complete
Project: .
Target: local-target.yaml
0 errors, 0 warnings in 1 file

This check matches the key record-status to the pack endpoint’s sqliteExtract.extractProfile: a profile with no binding is evidence.runtime.source-extract-unbound, and a binding no Source names is evidence.runtime.source-extract-unused. It does not open the file. On the target host, rstack evidence doctor also opens it.

Your export tooling writes the file with one evidence_extract row holding published_at, publisher, and extract_id. Evidence refuses an extract older than maximumExtractAgeSeconds.

Build and deploy a Registry Evidence project proves the file reachable on the target host with rstack evidence doctor.

Serve a lookup from a registry