Contextual Payments

Upload the pack

Download the bundle above. In your Scrydon deployment open Settings → Platform → Packs, drag the .tar.gz onto the drop zone, tick the unsigned-pack acknowledgement, and click Upload. It appears in your org catalog as Contextual Payments v1.0.3 with three contributes: 1 ontology, 2 data sources.

Enable it for a workspace-environment

Open the Ontology marketplace and enable Contextual Payments for your active workspace-environment. The two data sources are scheduled per workspace-environment by the platform's data-source reconciler.

Wait for the first tick

The data sources emit their rows on the first scheduled tick (this can take up to a minute after install while the reconciler schedules them). When it runs, two managed tables appear under Analytics → Tables: iso20022_pacs008_payments (6 rows) and core_banking_counterparties (5 rows).

See the binding auto-resolve with context

Open Ontology → Bindings and click the Payment binding row (silver_table → iso20022_pacs008_payments) to expand it — click anywhere on the row's left side, next to the ▸ caret. (Object bindings are expandable even with no columns mapped.) Because the binding's source.table matches the data source's table name, it resolves automatically — the header shows a core_banking_x · 96% source-context badge and the binding is Ready, and it already projects with the transforms applied.

Inside the expanded row, the first block is the Source context form (above the column-map editor — there's no separate button). What you should see: a set of labelled fields already filled in — because the pack shipped this binding's context. This is the metadata that says "this particular feed is an outgoing ISO 20022 credit-transfer statement from the BE core-banking system, and we're 96% sure of the mapping" — and it's what gets stamped onto every value this binding projects.

The fields, and what each one tells a downstream consumer:

Why it matters: the same canonical Payment could be fed by a second system using pacs.009, decimal amounts, a different jurisdiction. Recording this feed's context is what lets analytics and AI tell two amount values apart and explain where each came from — instead of silently flattening them into one ambiguous column. (You can edit any field and click Save to see it round-trip; the header badge updates to match.)

Inspect the per-property transforms

Once you've clicked Pick table (previous step), the column-map block becomes the editable editor: a row per mapped property, with a Transform dropdown beside each. Two of them come pre-selected — these are the transforms the pack shipped:

• amount ← amount_minor, transform divide_by_100. The feed's 1234556 projects as 12345.56.
• settlementTimestamp ← settled_at_utc, transform timezone_normalize (Europe/Brussels). The UTC instant is shifted to the booking jurisdiction.

The dropdown for every other property reads No transform (identity). You can change a transform and Save to author your own.

Both shipped transforms are flagged lossy, so a read's provenance.lossyProperties lists them — callers can see the projected value is a derived approximation, not the raw source byte.

Confirm the context travels with reads

The 96 % confidence and source context now travel with every projected instance instead of being stripped — each read carries a provenance envelope (confidence, bindingContext, lossyProperties). Where you can observe it:

• On the graph — click an instance node on /graph (next step). The detail panel shows a Provenance section: mapping confidence, the source context, and which properties are lossy approximations.
• In the Bindings workbench — the core_banking_x · 96% source-context badge on the binding header (the earlier steps) is the per-binding proxy.
• Via the API — POST /api/ontology/instances/query (the ontology-SDK instances.query surface) returns each row with its provenance envelope.
• Asserted in CI — apps/api-ontology/src/services/pack-install-contextual.integration.test.ts proves the envelope persists and resolves end-to-end on a real database.

(Optional) Explore the graph

Open /graph (Analytics → Graph). What you see first is the schema, not data: one node per object type — Payment, Counterparty, Originator, Beneficiary — with the header reading 4 TYPES · 2 LINK TYPES.

• Edges. Two link types wire the payment network: Payment —Initiated by→ Originator and Payment —Sent to→ Beneficiary (each pacs.008 row carries both endpoints, so one row = one edge). Counterparty has no hard edge — it is reconciled to Originator/Beneficiary through the contextual aliases below, which is the point: the relationship lives in the context layer, not a foreign key.
• Instance counts. Each type node shows its instance count (Payment 6, Counterparty 5, Originator 6, Beneficiary 6) once the tables exist; before that it reads — (unknown).
• ISSUES means a binding is not ready — it can't resolve its source table. Until the two tables exist (data-source tick or the CSV upload above), this is expected; once they exist the count drops to 0.
• To see instances: click a type node (e.g. Payment) and press Expand instances in the side panel (or double-click the node). Its rows render as instance nodes. The top search bar jumps straight to a specific instance.
• To see provenance: click an instance node. The detail panel shows a Provenance section — mapping confidence (96%), the source context (core_banking_x, ISO20022, pacs.008, BE…), and a Lossy row listing amount and settlementTimestamp (the transformed properties). Plain (non-contextual) bindings show no Provenance section.

Resolve a term contextually (the showpiece)

Open Ontology → Aliases. The pack's four aliases appear in the Registered aliases list (source imported). Scroll to the Test resolution panel at the bottom, type the local term Counterparty in the alias field, and fill the context inputs:

The same term, three different canonical concepts — surfaced with their confidence, ranked by how specifically the context matches. This is the contextual-reconciliation behaviour made visible.

(Optional) Suggest a mapping with AI

If your org has an LLM integration configured, expand a binding, click Pick table to open the editable editor (the same gate as the transforms — the Suggest with AI button lives inside that editor), then click Suggest with AI. It profiles the bound table's columns, asks the platformized model to map them to the binding's object type, and shows a review list (property ← column [transform] confidence%). Apply N pre-fills the editor for you to review and Save. It's advisory — nothing publishes without a human.