National Federated Compute Services – Arts & Humanities

Proof of Concept. V2.0

A node-based visual workflow editor for federating UK Arts & Humanities research data services. Built as part of the UKRI/AHRC Federation of Compute and Infrastructures programme. Conceptualised by Neil Jakeman, King's Digital Lab.

Drag nodes onto a canvas, connect them in any order, and run federated searches across multiple heritage data services simultaneously. Records from different services are normalised to a common schema, can be filtered and transformed, reconciled against Wikidata authorities, enriched with AI inference, and exported as CSV, JSON, or GeoJSON. Local document folders and images can be analysed using KCL's hosted inference API or a locally-running LLM via Ollama. IIIF manifests can be browsed and annotated with region markers, with cropped image snippets passed directly to inference models. Workflows can be saved to disk and reloaded.

Video tutorials

▶ Watch the instructional video playlist — 6 videos covering the core workflow concepts and node types.

Prerequisites

Node.js v18 or later (nodejs.org)
npm v9 or later (bundled with Node)
A modern browser — Chrome or Edge 86+ required for the LocalFolderSourceNode (File System Access API) and for the native save dialog in SaveSearchNode (falls back to an automatic download on Firefox); all other nodes work in Firefox too
KCL Inference API key — required only for KingsInference nodes; request access from King's Digital Lab
Ollama running locally on port 11434 — required only for Ollama nodes (hidden from sidebar by default; use KingsInference for hosted inference)
Puppeteer (installed automatically via npm install) — required only for the Wait for JS rendering option in URLFetchNode; the headless browser runs inside the Vite dev server

Installation

git clone https://github.com/kingsdigitallab/nfcs-poc.git
cd nfcs-poc
npm install
npm run dev

Open http://localhost:5174 in your browser.

The port is fixed at 5174 to avoid conflicts with other Vite projects.

Saving and loading workflows

Click 💾 Save in the top bar to download the current canvas as a workflow-YYYY-MM-DD.json file. This captures every node's position and configuration — query fields, filter/transform rules, prompts and settings, spatial bounding boxes, selectors, and ParamNode values.

Click 📂 Load to restore a saved workflow. The canvas is replaced with the saved nodes and edges. All nodes start in an idle state with no results — run them again to repopulate data.

Note: LocalFolderSourceNode folder handles and LocalFileSourceNode file handles cannot be serialised. After loading a workflow containing either, re-select the folder or file manually.

Node types

The sidebar groups nodes into collapsible categories. Click a group heading to collapse or expand it. Drag any node onto the canvas to add it.

Canvas

Node Description

QuickStart AI workflow planner. Describe a research question in plain English; the node calls the KCL inference API (arc:nexus) and returns a structured plan listing the most appropriate data service nodes, suggested queries, and commentary on source relevance. Click Instantiate workflow to place all recommended nodes on the canvas — search nodes, a SourceProfile for each source (or a shared Deduplicate → SourceProfile chain when multiple nodes of the same type are suggested), and TableOutput / MapOutput as appropriate. Wiring is created automatically. No handles — this node is a standalone planner. Requires a KCL API key.

Comment A free-floating annotation label. Add a title and body text to document your workflow. No connectors by default. Select the node to reveal resize handles — drag any edge or corner to resize. Easter egg: click the title field 5 times within 1.5 seconds to unlock hidden input/output handles — useful for illustrating conceptual workflow gaps (e.g. marking a "data retrieval" step between metadata services and processing nodes).

Input

Node	Description
Param	Holds a Text or Integer value. Connect its output handle to any search node input handle to inject a query parameter (e.g. wire a single query string into multiple search nodes at once).

Inspection

Node	Description
QuickView	Inspect the full, untruncated value of any field across upstream records. Pick a field from the dropdown; navigate records with ‹ / › buttons. Copy button per record. CSV/TSV values are paginated (50 rows per page). Large plain-text values are truncated at 50 000 chars.
ImageView	Resizable image viewer with two modes and a source output handle for piping images to inference nodes. Images mode — combobox field picker (type any dot-notation path, e.g. `europeana.thumbnail`; the dropdown suggests fields found in upstream records); a separate URL row accepts any public image URL directly (overrides the field picker when set). IIIF mode — accepts a IIIF Presentation API v2 or v3 manifest URL (pre-loaded with a Wellcome Collection example); navigates canvases with ‹ / › buttons; zoom-tiered resolution requests via IIIF Image API. See ImageView and IIIF region annotation.
HTMLPreview	Renders `fetchedHtml` from upstream records in a sandboxed iframe with a lightweight readability stylesheet. Click any element in the preview to capture its CSS selector — the selector is sent back to the parent page and can be pasted directly into an HTMLExtract node. Two modes: Captured (reads stored `fetchedHtml` from the results store) and Live (fetches the URL field of each record in real time).
SourceProfile	Displays the authored schema profile for any connected data source, enriched with runtime field statistics computed from the actual upstream records. Shows: source coverage and limitations; a completeness bar (`retrieved / total API results`); a field table sorted by population rate with expandable sample values from real records; cross-source correspondence hints (which fields can be joined or compared across sources). An optional AI Narrative section (KCL API key + model required) builds a structured prompt from all schema and completeness data and streams a research-quality assessment — provide a research question for a focused response. Drag the output handle to pass records through to any downstream node. Defaults to `arc:nano`; max tokens configurable (default 16 384) under Advanced.

Data Services

All active search nodes share a fixture mode for offline and workshop use — see Offline fixtures below.

Node	Service	Notes
ARIADNESearch	ARIADNE Infrastructure Portal	Pan-European archaeology data aggregator covering 40+ institutions across 23 countries. Direct browser fetch (permissive CORS). Inline fields: keyword query, limit, sort/order, and Fetch all results (paginates at 50 records/request). Collapsible Filters panel provides dropdowns for Resource type, Getty AAT subject, Native subject, Country, Data type, Period, and Contributor (ARIADNE aggregates records from the Archaeology Data Service and 40+ other institutions — filter by contributor to narrow to a specific provider). Citation metadata stamped on every record.
HSDSSearch	Heritage Science Data Service	UK heritage science data service aggregating records from Historic England, Historic Environment Scotland, Cadw (Wales), and other national bodies. Fetched via Vite proxy (no Cloudflare protection). Inline fields: keyword query, limit, sort/order, and Fetch all results (paginates at 50 records/request). Collapsible Filters panel: Resource type, Getty AAT subject, Native subject, Country (England/Scotland/Wales/Northern Ireland/Isle of Man), Data type, Period, and Contributor. Records include `hsds.*` namespace with landingPage, contributor, temporal, spatial, and subject arrays. Best for: scheduled monuments, listed buildings, UK historic environment records, built heritage, maritime archaeology.
BodleianSearch	Bodleian Digital Collections	Oxford's digital collections portal covering manuscripts, printed books, maps, photographs, coins, musical scores, and more. Inline fields: plain keyword query (e.g. `psalter`), limit (default 20), and sort order. Collapsible Filters panel: date range (from/to year), language (e.g. `Latin`), place of origin (e.g. `England`), completeness (fully digitised / partial), and musical notation presence. Records include `bodleian.` namespace with shelfmark, date range, and IIIF manifest URL — connect output to ImageView* in IIIF mode to browse manuscripts directly on the canvas. Fixture mode supported.
EuropeanaSearch	Europeana	Pan-European cultural heritage aggregator covering museums, galleries, libraries and archives. Direct browser fetch (permissive CORS). API key is pre-configured (🔒 Configured); wire a Param node to the `apiKey` handle to override with your own key from apis.europeana.eu. Inline fields: `query`, `limit` (up to 1 000 records via cursor-based pagination). Filters: Type, Reusability, media only. Records include `europeana.*` namespace with thumbnail, shownAt (original institution URL), rights, provider, and completeness.
GBIFSearch	GBIF Occurrence API	Biodiversity specimens and observations. Direct browser fetch (permissive CORS). Inline fields: free-text `q`, `scientificName`, `country`, `year`, `limit`.
LLDSSearch	Literary & Linguistic Data Service	DSpace REST API. Results filtered client-side. Uses a 24-hour localStorage cache; a Use cache toggle controls fallback during outages.
MDSSearch	museumdata.uk	HTML scraper (no public JSON API). Capped at 200 records; amber ⚠ badge when the total exceeds the cap.
SMGSearch	Science Museum Group	Digital collection covering science, technology, medicine, and social history. Records include `smg.manifest` (IIIF) — connect to ImageView for object browsing. Fixture mode supported.
VASearch	Victoria & Albert Museum	V&A Collection API v2. Filters: images only, object type, year made from/to. Records include `vam.manifest`, `vam.iiifImageBase`, `vam.thumbnail`, `vam.place`, `vam.objectType`, `vam.onDisplay`.
SPARQLSearch	Wikidata Query Service + Getty Vocabularies	(Experimental) Structured queries over SPARQL endpoints without writing SPARQL: a Builder with live entity/property lookup (type names, pick from Wikidata's own autocomplete), a plain-English ✨ NL assist with hallucination-proof QID grounding, and a Raw SPARQL escape hatch. Endpoint dropdown: Wikidata (full features), Getty AAT/TGN/ULAN (raw mode), British Library BNB (greyed out until BL restores its linked-data service). Results carry `_qid` for WikidataEnrich/MergeByQID and coordinates for MapOutput. See SPARQL Search below.
LoadSavedSearch	Local filesystem	Loads a `.nfcs.json` file saved by SaveSearch, or any raw `UnifiedRecord[]` JSON array exported by Export. Displays full provenance metadata: saved date/time, source breakdown with per-service record counts, and the original search parameters in a collapsible panel.
LocalFileSource	Local filesystem	Parses a single CSV, TSV, XML, or image file selected via a standard file picker (all browsers). Auto-detects the delimiter. Cast numeric strings to numbers toggle converts coordinate strings to floats.
LocalFolderSource	Local filesystem	Reads files from a user-selected folder via the File System Access API. Supports PDF (text extraction), XML/TEI, plain text, images, Shapefiles, and GeoJSON. Five typed output handles: `results` (all), `pdf`, `xml`, `text`, `image`, plus a GIS handle for Shapefile/GeoJSON layers. Requires Chrome or Edge 86+.
FrameSenseSource	Local filesystem	Reads a folder pre-processed by the FrameSense CLI and emits one record per shot. Each record carries the representative frame as an `imageDataUrl` (base64 JPEG), enabling direct vision inference via KingsInference. Existing FrameSense analysis (shot scale classifications from `scale_frames_sssabet`, VLM answers from `answer_frames_vlm`) is surfaced as `framesense.*` fields. See FrameSense workflows below.
SampleDataSource	Local filesystem + fixtures	Loads pre-packaged collection samples from `public/fixtures/` (e.g. Stonehenge antiquarian texts and modern archaeology papers, LLDS items, etc.). Useful for demonstrations, workshops, and testing without live API access. Emits five typed output handles: `results` (all), `pdf`, `xml`, `text`, `image`.

Filters and Transforms

Node	Description
FieldDistribution	Faceted bar chart of value frequencies for any field. Click bars to toggle them as filters — matching records are emitted on the output handle and update live as upstream data changes. Array-valued fields (`subject`, `country`, `creator`) are expanded so each element is tallied individually. Bars sorted by count descending, capped at a configurable Top N. A status bar shows how many records match the current selection with a ✕ clear button.
SmartFilter	Natural language → structured filter. Type a plain-English filter request (e.g. "Iron Age sites in England with coordinates", "objects made before 1700 with images") and click Translate & apply (or Ctrl/Cmd+Enter). The KCL inference API receives the actual field names and sample values discovered from your records, then returns a JSON conditions object which is evaluated deterministically — no `eval()`, no code generation. Each condition is displayed as a readable rule (`title contains "Iron Age"`). A match bar shows what proportion of records pass. Without a filter all records pass through unchanged; the ✕ button clears the filter and restores pass-through. Supports: `contains`, `equals`, `startsWith`, `endsWith`, `gt/lt/gte/lte`, `exists/notExists`, `in` — all handle array-valued fields. Requires a KCL API key; defaults to `arc:nano`.
FilterTransform	Filters records by condition and/or mutates field values. See Filter / Transform below.
SpatialFilter	Draws a bounding box on an interactive Leaflet map; filters upstream records to those within the bbox. Note: MapOutput also includes an integrated spatial bbox filter — for workflows where you want to visualise and filter in a single step, use MapOutput instead.
Deduplicate	Removes duplicate records based on a chosen field value. First occurrence is kept; subsequent records sharing the same value for that field are discarded. Records missing the chosen field always pass through. The footer shows `N in → M unique (K removed)`. Useful when aggregating results from multiple search nodes that may return overlapping result sets.
TimelineView	Resizable SVG horizontal timeline at year resolution. Handles ISO dates, bare years, and BCE dates. Filter mode — drag the date-range handles to restrict the visible window; records outside the range are suppressed on the output handle, making this a pass-through filter node as well as a visualisation. Toggle ⇤⇥ Fit to compress the full date range into the visible width. Pass-through output handle connects to any downstream node (TableOutput, Export, etc.).

Extraction and Enrichment

Node	Description
KingsInference	Sends each upstream record to KCL's OpenAI-compatible inference API and enriches the record with the model's response. Requires an API key. Supports vision mode — when enabled, image data URLs in records (from LocalFolderSource, ImageView, or IIIF region capture) are sent as multipart image content. Auto-detects `contentType: 'image'` records; or specify a field to use a particular image field. Includes a prompt recipe bar — save and recall prompt strategies across workflows. See KCL Inference below.
KingsInferenceByField	Lighter-weight KCL inference on a single chosen field. Two modes: per-record (enriches each record individually with live token preview) and aggregate (collects all values into one prompt for a summary response). Template variables: `{{value}}`, `{{field}}`, `{{count}}`, `{{values}}`. Model-dependent content truncation (arc:nano 12k, arc:lite 32k, arc:nexus 64k chars). Includes prompt recipe bar.
QuickNote	Human annotation node — display-only, no runner, pass-through. Three modes selectable via the Note · Structured · Score tab bar: Note — free-prose textarea writes to `_note` (shared across the workflow via the notes store and surfaced in TableOutput); Structured — configure named `{key, label}` fields once, then fill them per record in a clean form; the node assembles the values into a JSON gold-standard and writes it to a target field (default `_note`); Score — constrained per-criterion pickers (configurable scale) write `human_score` (+ flat `human_c` keys and optional prose reasons per criterion). The human counterpart to Evaluator*.
Evaluator	LLM-as-judge node. Scores a `candidateField` against a `referenceField` on the same record using an ARC model (temperature 0). Emits per-criterion JSON scores — never a single aggregate. Built-in rubric presets: Extraction agreement, Interpretive agreement, Rubric-from-note. Template tokens `{{__reference}}` / `{{__candidate}}`; writes `record.eval` (scores, reasons, raw, status) plus flat `eval_c*` columns. Displays a judge-vs-human agreement readout when a human-score field is present. Tolerant JSON parsing — always recovers; marks failures as `parse_error` status rather than throwing. Requires a KCL API key.
URLContentFetch	Follows a URL field in each record, fetches the page (optionally via headless browser for JS-rendered pages), and adds `fetchedContent` (plain text) and `fetchedHtml` (cleaned body HTML).
HTMLExtract	Extracts a targeted section from `fetchedHtml` using a CSS selector. Connect HTMLPreview to visually browse the page and click-capture selectors. Toggle Preserve HTML structure to write raw HTML rather than stripped text — useful for passing markup to an inference model.
Reconciliation	Reconciles a chosen field against a Wikidata authority. See Reconciliation below.
WikidataEnrich	Fetches selected Wikidata properties for any reconciled QID field and appends them as `wd_*` fields. See Wikidata enrichment and linking below.
MergeByQID	Groups records from multiple upstream sources by shared Wikidata QID, producing one merged record per entity. See Wikidata enrichment and linking below.
XMLExtract	Evaluates an XPath expression against the `content` field of upstream records (typically XML or TEI documents). A schema inspector panel shows the element tree of the first record; click any element to build the XPath. Strips default XML namespaces before evaluation. Writes result to `xmlContent`.
Geocoding	Enriches a chosen place-name field using a two-tier gazetteer: Getty TGN (name search servlet → Linked Art JSON for coordinates) and Wikidata (`wbsearchentities` + P625 coordinates). Scores candidates using Dice string similarity + tier weight + cross-gazetteer corroboration. Auto-resolves when top score ≥ confidence threshold and gap to second candidate ≥ 20%; ambiguous results surface in an inline review panel for manual confirmation. Confirmed choices stored per node and persist in saved workflows. Candidate lists cached 30 days in localStorage; "clear cache" button forces a fresh network query. Adds `decimalLatitude`, `decimalLongitude`, and a `geocoding.` namespace (geocoded status, source, authority URI, candidates, raw/cleaned place string, confidence). Connect output to MapOutput* to plot geocoded records on a map.
SmartGeocoder	LLM-assisted place extraction and geocoding. Scans upstream records for place-name hints — either from all string fields or a user-selected subset — and calls the KCL inference API (`arc:lite` default) to identify the most likely canonical place name. The extracted place name is then resolved through the same Getty TGN → Wikidata two-tier gazetteer used by the regular Geocoding node, writing `decimalLatitude`, `decimalLongitude`, and a `smartGeo.*` namespace. Designed for records where the place name is embedded in prose (e.g. a manuscript description or an archival summary) rather than held in a dedicated field. Requires a KCL API key.

Output

Node	Description
Citation	Paginated bibliography drawn from `_citation` metadata stamped by source runners. Supports Copy all and Download .txt for a formatted reference list.
Export	Downloads upstream records as CSV, JSON, or GeoJSON. `*_reconciled` objects are expanded to `_qid/_label/_confidence/_status` columns in CSV.
JSONOutput	Syntax-highlighted JSON viewer. Double-click to expand to full-screen.
KingsInferenceOutput	Card-based display of KCL inference responses. Each record gets an expandable card showing the response, model used, and processing timestamp. Copy button per card.
MapOutput	Leaflet map. Plots records with `decimalLatitude`/`decimalLongitude`. Click a marker for a popup with title, date, and source link. Integrated spatial filter: click Draw bbox, drag a bounding box on the map, then Run ▶ — only records within the box are emitted; records outside are dimmed. A coordinate summary shows N/S/E/W bounds. A green results output handle pipes the filtered (or all) records to downstream nodes. Also accepts GIS vector layers via the GIS handle from LocalFolderSource.
TableOutput	Paginated table. Merges records from multiple upstream nodes. Pass-through output handle for chaining to Map, Export, etc. Double-click to expand to full-screen. Toolbar: show all columns + expand namespaces (flattens service namespace objects into dot-notation columns). Page size selector (10 / 25 / 50 / 100 rows). Column sort: click any column header to sort ascending, click again for descending, third click clears the sort. Text filter: search box above the table filters across all fields (including namespace sub-objects) live as you type.
ComparisonReport	Read-only evaluation report — no runner, skipped by Run All. Map five report roles (original, note / reference, response / candidate, judge score, human score) to upstream fields via dropdowns. Renders per-record side-by-side cards and an aggregate agreement matrix (counts, means, and percentage-agreement only — no inferential statistics). Divergence counts double as live card filters; click a count to show only divergent records. Double-click the node to open a full-screen projector view for presentations. Agreement is computed over scored records only.
SaveSearch	Serialises upstream records with a metadata envelope to a `.nfcs.json` file. Shows record count, per-source breakdown, and auto-suggested filename. Native Save As… dialog on Chrome/Edge; auto-download on Firefox.

Data flow

ParamNode ─┐
           ▼
  ARIADNESearch       ─────────────────────────────────────────────────┐
  HSDSSearch          ─────────────────────────────────────────────────┤
  BodleianSearch      ─────────────────────────────────────────────────┤
  EuropeanaSearch     ─────────────────────────────────────────────────┤
  GBIFSearch          ─────────────────────────────────────────────────┤
  LLDSSearch          ─────────────────────────────────────────────────┤
  MDSSearch           ─────────────────────────────────────────────────┤
  LocalFileSource     ─────────────────────────────────────────────────┤
  LoadSavedSearch     ─────────────────────────────────────────────────┤
                       ▼                                              │
              FilterTransformNode ──────────────────────────────────── ┤
              SpatialFilterNode   ──────────────────────────────────── ┤
              FieldDistributionNode ─────────────────────────────────── ┤  ← click bars to facet-filter
              TimelineView          ─────────────────────────────────── ┤  ← drag range handles to filter
                                                                       │
  LocalFolderSource ──► KingsInference ──────────────────────────────── ┤
  ImageView (IIIF) ──► KingsInferenceByField ─────────────────────────── ┤
                       URLContentFetch ──► HTMLExtract ──────────────── ┤
                       XMLExtract       ──────────────────────────────── ┤
                       Reconciliation ──► WikidataEnrich ──► MergeByQID ┤
                                                                        ▼
                                                TableOutput ──► Export
                                                Citation
                                                JSONOutput
                                                MapOutput ◄── LocalFolderSource (GIS)
                                                KingsInferenceOutput
                                                SaveSearch ◄── (any data-handle source)

All data nodes expose a data input handle (left) and a results output handle (right) unless otherwise noted. You can chain them in any order and branch to multiple output nodes simultaneously.

The useUpstreamRecords hook merges records from all edges connected to a node's input handle, so a single Table or Map node can aggregate several source nodes at once.

Execution model

▶ Run (on individual nodes) — execute that node only.
▶▶ Run All (top bar) — discovers every runnable node, builds a topological order using Kahn's algorithm, and executes nodes wave-by-wave: all source nodes in parallel first, then each processing layer in dependency order. If one node errors, downstream dependants are skipped but unrelated branches continue.

All node types are included in Run All except LocalFolderSource and LocalFileSource (file/folder selection requires a user gesture and cannot be automated). Run those nodes manually before clicking Run All.

Node grouping

Nodes can be bundled into a labelled, collapsible group for visual organisation. Groups are purely cosmetic — they do not affect data flow.

Creating and managing groups

Select two or more nodes on the canvas (click, Shift+click, or drag a selection box).
Click 📦 Group (N) in the top bar — the selected nodes are wrapped in a blue dashed container with a default label.
Double-click the label to rename it.
Select a group node and click 📤 Ungroup to dissolve it — all children are returned to the canvas at their absolute positions.

Collapsing and expanding

Each group has a small toolbar (▼ / ▶) at the top-right corner. Click ▼ to collapse the group into a compact pill; click ▶ to expand it again. Collapsed groups still participate in data flow — edges are re-routed through the group pill.

Auto-grow

A group automatically expands its bounding box when a child node is resized or when a new node is dragged inside it (expandParent). Groups are also restored to their expanded state when a workflow is reloaded.

Duplicating groups

The ⧉ toolbar button duplicates a group together with all its children and any internal edges. External edges (connecting group children to nodes outside the group) are not duplicated.

The UnifiedRecord schema

Every adapter maps its raw API response to UnifiedRecord before writing to the canvas. Output nodes consume only UnifiedRecord[].

id            — globally unique, service-prefixed: "gbif:12345", "ariadne:<hash>", "bodleian:<id>"
_source       — service identifier: "gbif" | "llds" | "ariadne" | "mds" | "europeana" | "bodleian"
_sourceId     — native record ID within the service
_sourceUrl    — link back to the record in the service's own UI
_pid          — persistent identifier (DOI, Handle, ARK) when available
_citation     — citation metadata stamped by source runners

title         — best available display title
description   — abstract or description
creator       — author(s) — string or string[]
date          — publication or event date
subject       — subject keywords — string or string[]
language      — language code

decimalLatitude, decimalLongitude  — used by MapOutput

gbif.*        — full raw GBIF occurrence object
llds.*        — LLDS handle, branding, itemType
ariadne.*     — ARIADNE temporal, country, spatial, contributor, subjects, identifier
hsds.*        — HSDS landingPage, contributor, temporal, spatial, ariadneSubject, nativeSubject, derivedSubject, dataType, accessRights
mds.*         — MDS field map (condition, materials, dimensions, provenance, …)
europeana.*   — provider, dataProvider, rights, thumbnail, shownAt, completeness
bodleian.*    — shelfmark, objectType, dateRange, manifest (IIIF manifest URL)

fetchedUrl, fetchedContent, fetchedHtml, fetchStatus, fetchedAt  — added by URLContentFetch
htmlSelector                                                      — added by HTMLExtract
xmlContent, xmlXPath                                              — added by XMLExtract
kclModel, kclPrompt, kclResponse, kclProcessedAt                  — added by KingsInference nodes
ollamaModel, ollamaPrompt, ollamaResponse, ollamaProcessedAt      — added by Ollama nodes (hidden)

content, contentType, mimeType  — FileRecord fields (from LocalFolderSource / ImageView)

After reconciliation, records also carry ${fieldName}_reconciled keys (see Reconciliation).

KCL Inference

KingsInference and KingsInferenceByField connect to KCL's hosted OpenAI-compatible inference API (https://api.ai.create.kcl.ac.uk/v1) via the /kcl-proxy route. An API key is required.

Setup

Drag a KingsInference node onto the canvas.
Enter your API key in the API Key field. The node fetches available models from the API and populates the model dropdown.
Configure the system prompt, user prompt template, temperature, and max tokens.

Prompt templates

Use {{fieldName}} placeholders in the user prompt template. Click ▼ fields to see the available substitution tokens drawn from the first upstream record. Common tokens:

Token	Value
`{{content}}`	Primary text content of the record (`content`, `fetchedContent`, `description`, or `title` in order of availability)
`{{title}}`	Record title
`{{description}}`	Record description / abstract
`{{anyField}}`	Any field from the record by name
`{{_lineage}}`	The context accrual token — a plain-English narrative of the pipeline that produced the records. See Context accrual below.

Vision mode

Tick Vision to enable multipart image content. When active, the node automatically detects image data URLs in upstream records and sends them alongside the text prompt to any vision-capable model.

Auto-detect: first checks for contentType === 'image' (records from LocalFolderSource, ImageView), then scans all string fields for data:image/ prefixes.
Field override: select a specific field from the dropdown when multiple image fields are present.
In vision mode, {{content}} resolves to description or title rather than the raw data URL.

KingsInferenceByField

Works identically but processes a single chosen field per record. Per-record mode enriches each record; aggregate mode collects all field values into one prompt for a summary response.

Output

Enriched records gain kclResponse, kclModel, kclPrompt, and kclProcessedAt fields. Connect a KingsInferenceOutput node to display responses as expandable cards, or pass to TableOutput or Export.

Prompt recipes

Both KingsInference and KingsInferenceByField include a prompt recipe bar for saving and recalling prompt strategies. Built-in recipes are included (marked with ★):

Standard node recipes (KingsInference):

Extract persons — JSON
Extract places — JSON
Summarise briefly

Field node recipes (KingsInferenceByField):

Per-record: Extract persons from field — JSON, Extract places from field — JSON, Summarise record field
Aggregate: Thematic summary, List unique entities

To use: select a recipe from the dropdown, click Apply to populate the system prompt and template. Click Save… to create custom recipes — they persist in localStorage and are available across sessions.

Context accrual — the `{{_lineage}}` token

Put {{_lineage}} anywhere in a KingsInference, Ollama, or Evaluator prompt and, at run time, it is replaced with a plain-English narrative of the upstream pipeline history — which services were searched with what terms, how records were filtered, transformed, reconciled, geocoded, or merged, and how many records flowed through each stage. The model sees not just the records but how they came to be, which materially improves summaries, comparisons, and judgements.

Example substitution for a two-branch workflow:

Branch A:
  1. Searched ARIADNE (pan-European archaeology portal) for "hillfort" with filters: Country=United Kingdom; retrieved 120 results.
Branch B:
  1. Queried Wikidata (SPARQL) — instances of Q744099; retrieved 95 results.
Then:
  1. Merged records from multiple sources by shared Wikidata QID: 61 merged entities, 14 unmatched (dropped).
  2. Filtered records where title contains "Iron Age": 23 of 61 records passed.

How it works (design in docs/context-accrual.md):

The lineage is derived on demand from the node graph — collectLineage(nodeId, nodes, edges) walks the upstream subgraph over data-flow edges (param wires are configuration, not data) and returns a topologically ordered history; lineageToNarrative(graph) renders it LLM-ready. Nothing is stamped on records.
Record counts are read from the results store with pass-through inheritance, so display-only nodes (TableOutput, QuickNote, FieldDistribution) sitting in the chain report the records flowing through them rather than breaking the story.
Linear chains render as a numbered list; parallel branches as lettered sections with shared ancestors described once; joins (e.g. MergeByQID) and everything after them under Then:. A ~2,000-character budget drops the earliest steps whole — never mid-sentence.
If an upstream node's settings changed since it last ran, the narrative is prefixed with an explicit staleness warning.
Templates without the token are untouched — zero cost unless you opt in.

FrameSense workflows

FrameSense is a Python CLI that pre-processes video collections into a structured folder hierarchy of shots and frames. This app reads a pre-processed collection — it does not process video itself.

Pre-processing (offline, outside this app)

Run these FrameSense operators on your video collection:

python framesense.py make_shots_scenedetect   # auto-detect shot boundaries (PySceneDetect)
python framesense.py make_frames_ffmpeg        # extract first, middle, last frame per shot
python framesense.py scale_frames_sssabet      # optional: classify shot scale (ECU/CU/MS/FS/LS)

The resulting folder structure is:

<collection>/
  <video>/
    [<clip>/]
      shots/
        001/
          middle.jpg      ← representative frame
          frames.json     ← existing analysis (shotScale, VLM answers if run)

Using FrameSenseSource in the workflow

Drag FrameSenseSource onto the canvas.
Choose a Frame filter — Middle (recommended, one image per shot) keeps memory usage low.
Click 🎬 Pick Folder and select the pre-processed collection root.
The node scans recursively and emits one UnifiedRecord per shot, containing:
- framesense.collection, framesense.video, framesense.clip, framesense.shot
- framesense.frameFile — the file loaded (e.g. middle.jpg)
- framesense.shotScale — if scale_frames_sssabet was run (e.g. MS, CU)
- Any existing VLM answers already in frames.json as framesense.<questionKey>
- imageDataUrl — base64 JPEG of the frame

Run All skips FrameSenseSource — it requires a user gesture. Pick the folder and click Re-scan manually before running downstream nodes.

Wiring for vision inference

Connect FrameSenseSource results → KingsInference data. KingsInference auto-detects imageDataUrl and shows the Vision checkbox — tick it. The image is attached as a multipart message alongside your prompt; {{imageDataUrl}} does not need to appear in the template text.

Recommended prompt for a quick functional test:

System: You are a film analyst. Be concise.

Prompt:

Describe this shot in one sentence. Note the apparent shot scale (extreme close-up,
close-up, medium, full, or long shot) and what is depicted.

This is immediately verifiable: if scale_frames_sssabet pre-processing was run, compare the model's shot scale description against framesense.shotScale in TableOutput.

For structured output suitable for downstream processing, use a JSON prompt:

Prompt:

Analyse this frame. Respond in JSON with these keys:
"description" (one sentence), "shot_scale" (one of: ECU, CU, MS, FS, LS),
"setting" (interior/exterior/unclear), "people_visible" (true/false).

The kclResponse field then contains parseable JSON you can filter on or aggregate.

Aggregate summary with KingsInferenceByField

After per-shot inference, wire a KingsInferenceByField node downstream in aggregate mode to summarise across a whole video:

Field: kclResponse
Mode: Aggregate

System: You are a film analyst helping to catalogue archival video footage for humanities research.

Prompt:

The following are shot-level analyses from a video, one per line. Each contains
a description, shot scale, setting, and whether people are visible.

{{values}}

Write a short catalogue summary (3-5 sentences) covering: the overall subject and
setting of the footage, the range of shot scales used, and whether people feature
prominently. Then list 3-5 keywords suitable for archival indexing.

Tip — context window management: if the collection is large, the concatenated shot analyses may approach the model's context limit. Use a FilterTransform node upstream of KingsInferenceByField to narrow records to a single framesense.video or framesense.collection before aggregating.

Recommended workflow

[FrameSenseSource]
       ↓ results
[FilterTransform]          ← optional: filter by framesense.shotScale or framesense.collection
       ↓ results
[KingsInference]           ← Vision on, per-shot question (JSON prompt recommended)
       ↓ results
[KingsInferenceByField]    ← aggregate mode, field: kclResponse, video summary
       ↓ results
[TableOutput]
[Export]                   ← CSV/JSON for archival deposit

Human evaluation and LLM-as-judge

Three nodes work together to support rigorous human and model-based evaluation of AI-generated outputs:

[Source node]
      ↓ data
[KingsInference]          ← generate candidate responses (kclResponse)
      ↓ results
      ├──────────────────────────────────────────────────────────────────────┐
      ▼                                                                      ▼
[QuickNote — Note / Structured mode]    [QuickNote — Score mode]
  Annotate records with a gold-standard    Rate each record's candidate against
  reference (free prose or structured      human-defined criteria
  JSON into _note or a custom field)       → human_score + human_c* keys
      ↓                                              ↓
      └────────────────────────┬────────────────────┘
                               ▼
                         [Evaluator]
                   LLM-as-judge: scores candidateField
                   vs referenceField, per-criterion
                   → eval.scores, eval_c* keys
                   + judge-vs-human agreement readout
                               ↓
                      [ComparisonReport]
                   Side-by-side cards + aggregate matrix
                   Judge score / human score comparison

The three roles

Role	Node	Field written
Candidate	KingsInference / KingsInferenceByField	`kclResponse` (or any field)
Reference / gold standard	QuickNote (Note or Structured mode)	`_note` or a custom field
Human score	QuickNote (Score mode)	`human_score`, `human_c*`
Judge score	Evaluator	`eval.scores`, `eval_c*`
Report	ComparisonReport	— read-only display

Criteria alignment

Criteria are matched by convention, not code. The criterion keys in QuickNote (Score mode) must use the same names as the criteria in the Evaluator rubric for the agreement maths in ComparisonReport to be meaningful. A mismatch produces empty agreement cells, not an error.

Running the pipeline

QuickNote nodes are annotation-only and do not appear in the ▶▶ Run All execution graph. Fill them manually (or use Structured mode to speed up gold-standard entry). Evaluator runs automatically as part of Run All. ComparisonReport is also annotation-only and skipped by Run All — open it to review results after Evaluator has run.

ImageView and IIIF region annotation

ImageView is a resizable node in the Inspection group. It has a source output handle (green, top right) so the currently displayed image can be piped to inference nodes.

Images mode

Field picker — select any field from upstream records that contains an image data URL or remote HTTP image URL.
URL row — paste any public image URL directly; this overrides the field picker when set.
The output handle emits a single record: { content: dataUrl, contentType: 'image', mimeType, title, ...sourceRecord }.

IIIF mode

Accepts IIIF Presentation API v2 or v3 manifest URLs. Upstream records from BodleianSearch (and other services that include IIIF manifests) populate a From upstream picker automatically — no copy-pasting required.

Zoom requests are served at tiered resolutions via the IIIF Image API (!600,600 → !1200,1200 → !2400,2400 → max) to avoid fetching full-resolution masters unnecessarily.

Region annotation

Once a manifest is loaded, the region annotator toolbar appears above the canvas navigation:

Click + Region to enter draw mode (button turns orange).
Drag a rectangle over any area of the displayed image. A blue semi-transparent box is committed and labelled automatically (Region 1, Region 2, …).
Delete any region by clicking the red × in its top-right corner.
Click Capture (or Capture N when regions exist) to fetch each region as a base64-encoded image and write the records to the output handle.

How capture works:

For IIIF Image API services: each region uses the IIIF pct:x,y,w,h parameter to request only the cropped area at up to 1024 × 1024 px ({serviceUrl}/pct:.../!1024,1024/0/default.jpg).
For direct-URL canvases (no IIIF Image API): the full canvas image is fetched.
Direct fetch is tried first; falls back to /url-proxy for CORS-restricted servers.
Each output record: { content: dataUrl, contentType: 'image', mimeType: 'image/jpeg', title, regionIndex, regionBounds, canvasLabel, manifestTitle, ... }.
If no regions are drawn, Capture fetches the whole canvas as a single record.

Connect the output handle to KingsInference (with Vision enabled) to send annotated IIIF image regions to the inference model. Regions and their labels are saved in the workflow file.

Info panel

Toggle ℹ Info to reveal: IIIF manifest metadata (title, date, attribution, provider, rights, pixel dimensions from info.json, tile size, compliance profile) or local image metadata (pixel dimensions, estimated file size, and EXIF — make/model, date taken, exposure, aperture, ISO, GPS coordinates — parsed inline from the first 64 KB of JPEG files without external libraries).

Filter / Transform

FilterTransform operates in three modes (selectable via tabs):

Filter mode

Add one or more filter rows. Each row specifies:

Field — any field, including dot-notation namespace fields (e.g. gbif.stateProvince, ariadne.contributor)
Operator — contains, =, starts with, >, <, is empty, not empty
Value — text or number

Multiple rows are combined with an AND / OR toggle.

Transform mode

Operation	What it does
Rename field	Copies a field to a new key. Optional drop checkbox removes the original.
Lowercase / Uppercase	In-place case conversion. Array values converted element-by-element.
Truncate	Trims a field to a maximum character length and appends `…`.
Extract	Slices a substring by start/end index, or captures a regex match. Writes to a new field.
Concatenate	Merges two fields into a new key with a configurable separator.

Both mode

Filter runs first, then transforms are applied to the reduced set.

Reconciliation

ReconciliationNode enriches a chosen field by matching its unique values against a Wikidata authority via the W3C Reconciliation API.

Connect an upstream node to the data handle and select the field to reconcile.
Select the authority:

Field	Authorities
`creator`	Wikidata People (Q5)
`country`, `spatialCoverage`	Wikidata Places (Q618123)
`scientificName`, `species`, `genus`	Wikidata Taxa (Q16521)
`institutionCode`	Wikidata Organisations (Q43229)
(any other field)	Wikidata Items

Set the confidence threshold (0.5–1.0, default 0.8) and click ▶ Reconcile.

Each augmented record gains a ${fieldName}_reconciled key. In TableOutput, reconciled cells render as coloured pills — green (resolved, confidence ≥ threshold) or amber (flagged for review). QIDs are clickable links to wikidata.org.

Wikidata enrichment and linking

WikidataEnrich

Fetches structured properties from Wikidata for any reconciled field and appends them as wd_* fields (e.g. wd_IUCNStatus, wd_country). Works directly against the Wikidata API — no proxy required.

Tick the properties you want grouped by domain (General, Taxon, Place, Person, Heritage) or enter custom P-IDs. wikibase-item values are resolved to English labels in a second batch call.

Recommended order: Reconciliation → MergeByQID → WikidataEnrich — merge first so enrichment is applied once per entity rather than once per record.

MergeByQID

Groups records from any number of upstream sources by shared Wikidata QID and emits one merged record per entity. Each merged record contains _qid, _sourceCount, _sources, and all source fields prefixed by service name (e.g. gbif_scientificName, ariadne_title). Toggle Keep unmatched records to pass through records with no reconciled QID unchanged.

SPARQL Search

(Experimental group — enable Advanced mode to see it.) Query knowledge graphs over SPARQL without needing to know SPARQL — or any entity identifiers. The node solves the two things that normally make SPARQL unusable for non-specialists: finding the right IDs and writing the query.

Live entity and property lookup

Every place the query needs an identifier is a live, as-you-type search backed by wbsearchentities — the same API behind Wikidata's own autocomplete (browser-direct, no key needed):

find (instance-of): type hillfort → pick hillfort (Q744099) from a dropdown showing label, Q-id, and disambiguating description. Curated suggestions appear instantly when the box is empty.
Property filters: the property box searches Wikidata's properties — type time period → P2348, artist → creator (P170). The curated property groups appear as instant seeds.
Filter values: type a name (J. M. W. Turner → Q159758) or leave free text for a CONTAINS match.
Any Q-id/P-id already in the node shows a resolved-label chip (e.g. Q3305213 → painting) linking to Wikidata — so you always know what an opaque identifier actually is. A red chip flags a nonexistent entity.

Every builder change regenerates the query into a read-only preview; ✎ Edit as raw SPARQL is the escape hatch (hand edits are kept until a builder control changes).

✨ NL assist with QID grounding

Type a research question in plain English (e.g. "paintings by either J. M. W. Turner or John Constable"), pick an ARC model (arc:nano/lite/nexus/apex), and click ✨. The generated SPARQL lands in Raw mode for review — but first every wd:Q… it references is verified against live Wikidata:

The model must declare what each QID it used is meant to be; the app checks the QID exists and that it appears in the live search results for that name (alias-aware — "William Turner" correctly verifies Q159758, label "J. M. W. Turner").
Hallucinated or mismatched QIDs are automatically replaced with the top live-search hit, and a per-entity report appears under the query: ✓ Q159758 J. M. W. Turner (verified) / ⚠ Q11436 "aircraft" → Q159758 J. M. W. Turner (from "J.M.W. Turner") ▾ (auto-repaired — click for alternates, including one-click restore of the original) / ✗ (no match found). This matters: LLMs routinely emit plausible-looking but wrong QIDs, which produce syntactically valid queries that silently return zero rows.
Verification is tolerant — if Wikidata is unreachable the query is kept unchanged, never blocked.

Endpoints

Endpoint	Status	Features
Wikidata (default)	Live	Builder, keyword seed, ✨ NL assist + grounding, entity/property lookup
Getty Vocabularies (AAT/TGN/ULAN)	Live	Raw SPARQL only (gvp/xl/luc/skos prefixes built in); switching inserts a working AAT sample query
British Library BNB	Offline	Greyed out — the BNB linked-data platform has been down since the BL cyber-incident; the entry and proxy route are ready to enable the day BL restores it

Old saved workflows carry no endpoint field and load against Wikidata unchanged. Non-Wikidata endpoints force Raw mode (the builder and assist are Wikidata-specific and would mislead).

Wiring and outputs

Wirable query (keyword) and limit handles at the standard search-node positions; a query without an explicit LIMIT gets the limit row appended (an in-query LIMIT wins).
Result bindings land under the sparql.* namespace; ?item/?itemLabel/?itemDescription map to id/title/description, WKT Point(lon lat) values map to decimalLatitude/decimalLongitude (→ MapOutput), and the trailing Q-id of ?item is written to _qid — so results plug straight into WikidataEnrich and MergeByQID alongside reconciled records from other services.
Fixture mode (📦) works as on every search node; error responses are condensed to a readable message (e.g. Wikidata 400: MalformedQueryException) instead of a Java stack trace.

Worked example

"Paintings by either Turner or Constable" — builder filters AND together, so "either" needs one raw edit:

Keep the default find: painting; add filter creator (P170) → type J. M. W. Turner, pick Q159758.
Click ✎ Edit as raw SPARQL and change ?item wdt:P170 wd:Q159758 . to ?item wdt:P170 ?creator . VALUES ?creator { wd:Q159758 wd:Q159297 }.
Set the limit and ▶ Run (~1,100 paintings match).

Or just ask the ✨ assist for it — or run two SPARQL nodes (one per artist) into a shared TableOutput, the canvas-native way.

Data-reality tip: Wikidata's tagging is uneven — e.g. only ~27 of 4,150 UK hillforts carry a time period statement, so a hard P2348 = Bronze Age triple discards nearly everything. For period-faceted archaeology, combine sources: pull coordinates from SPARQL, facet periods via ARIADNESearch, and merge — that federation is what this workbench is for.

URL fetching and section extraction

URLContentFetch

Follows a URL field in each upstream record and fetches the page, adding fetchedContent (plain text) and fetchedHtml (cleaned body HTML). URL field is auto-detected from fields whose name or value suggests a URL; also scans service namespace objects for dot-notation paths like ariadne.identifier.

Options: Wait for JS rendering (Puppeteer), Wait for strategy, Max chars, Timeout.

HTMLExtract

Extracts a targeted section from fetchedHtml using a CSS selector, writing the result into fetchedContent. Connect HTMLPreview → HTMLExtract for a fully visual selector workflow: click any element in the preview pane to capture its selector. Toggle Preserve HTML structure for markup-aware extraction.

Export

Export downloads upstream records. Select format:

Format	Description
CSV	Flat table. `*_reconciled` objects expanded to `_qid`, `_label`, `_confidence`, `_status` columns. Namespace objects excluded.
JSON	Full record graph as a pretty-printed JSON array.
GeoJSON	`FeatureCollection` of records with `decimalLatitude` and `decimalLongitude`.

Files named nfcs-export-YYYY-MM-DD.{ext}.

Saved search caching

SaveSearch and LoadSavedSearch cache search results for reproducible demos and offline use.

Saved files use a .nfcs.json envelope wrapping the record array with _nfcs metadata: savedAt, sources, sourceCounts, recordCount, searchParams (the full configuration of every upstream source node, keyed by type and ID).

Any JSON file produced by Export (format: JSON) can also be loaded into LoadSavedSearch — it will display as "N records — no metadata (raw export)".

Workshop deployment and retrieving saves

When running the Docker deployment (deploy/express-server branch), every time a participant clicks 💾 Save a copy of their workflow is silently posted to the server and written to /app/data/workflows/ inside the container, in addition to the usual local browser download. Files are stored in a named Docker volume (workflow_saves) so they survive container restarts.

File naming

Each file is named by UTC timestamp plus a random suffix to prevent collisions when multiple participants save simultaneously:

2026-05-28T14-30-00-000Z-x3k9mf.json

Files contain the full workflow JSON (nodes, edges, configuration) plus two server-injected fields:

Field	Description
`serverReceivedAt`	ISO timestamp of when the server received the save
`remoteIp`	Participant's IP address — useful for grouping saves by participant

Listing saves (without extracting)

docker compose exec app ls /app/data/workflows/

Extracting all saves to a local folder

Using Docker Compose v2 (docker compose cp):

docker compose cp app:/app/data/workflows/ ./workshop-saves/

This creates a workshop-saves/ directory in your current folder containing all .json files.

If you need to use plain docker cp instead, first get the container name:

docker ps --format '{{.Names}}'
# e.g. nfcs-poc-app-1

docker cp nfcs-poc-app-1:/app/data/workflows/ ./workshop-saves/

After extraction

Each file is a standard JSON object you can open in any text editor or analyse with tools like jq:

# Count saves per participant IP
jq -r '.remoteIp' workshop-saves/*.json | sort | uniq -c | sort -rn

# List all node types used across all saved workflows
jq -r '[.[].nodes[].type] | unique[]' workshop-saves/*.json | sort | uniq -c | sort -rn

Offline fixtures

Every active search node ships with a fixture mode for offline and workshop use.

Control	Behaviour
📦 toggle	When checked, ▶ Load fixture loads pre-baked results from `public/fixtures/` instead of calling the live API.
💾 button	Downloads the current results as a `{nodeType}-{query}.json` fixture file. Drop into `public/fixtures/` and commit to make it available to all.

The fixture filename derives from the search query (inline or wired from a ParamNode), e.g. bodleianSearch-manuscript.json. Mismatches produce a descriptive 404 error naming the expected file.

Bundled fixtures

Query	ARIADNE	GBIF	LLDS	MDS	Europeana
`stonehenge`	✓	✓	✓	✓	✓
`wordsworth`	✓	✓	—	✓	✓
`roman coin`	✓	✓	—	✓	✓

LLDS collection samples

public/fixtures/LLDS Collections/ contains actual collection items from the Oxford Text Archive — TEI-XML transcriptions, Dublin Core and METS metadata, EPUBs, and plain-text versions for Stonehenge and Wordsworth topics. Use with LocalFolderSource at workshops.

CORS and the dev proxy

Prefix	Target	Reason
`/llds-proxy/…`	`https://llds.ling-phil.ox.ac.uk/llds/…`	No CORS
`/mds-proxy/…`	`https://museumdata.uk/…`	No CORS
`/reconcile-proxy/…`	`https://wikidata.reconci.link/…`	307 redirect strips CORS headers
`/kcl-proxy/…`	`https://api.ai.create.kcl.ac.uk/…`	KCL inference API — avoids CORS for hosted inference
`/ollama/…`	`http://localhost:11434/…`	Cross-port CORS for local Ollama
`/url-proxy?url=…`	any URL	Vite middleware; sidesteps CORS for arbitrary URL fetching
`/hsds-proxy/…`	`https://hsds.ac.uk/…`	No CORS

Production note: This proxy is development-only. The deploy/express-server branch includes an Express server that replicates all proxy routes for deployed instances.

KCL Assistant

The top bar contains a 💬 Assistant button that toggles a right-hand chat panel backed by KCL inference.

Model: arc:apex via /kcl-proxy/v1/chat/completions (streaming, server-sent events).
Rendering: Responses are rendered as GitHub-Flavoured Markdown — tables, code blocks, and lists display correctly.
Knowledge: The assistant carries a full built-in node reference (all node types, handles, field names, prompt tokens, and architectural notes) so it can answer questions about the interface without needing any configuration.

What you can ask

"What node should I use to extract text from a PDF?"
"How do I reconcile a field against Wikidata?"
"Suggest a workflow for comparing AI responses against human annotations."
"What fields does ARIADNESearch add to a record?"

Setup

A default KCL API key may be pre-configured. If the panel shows an API error, enter a valid key in any KingsInference node — the same key is used by the assistant panel. You can also override it directly in the src/components/ChatSidebar.tsx API_KEY constant.

Usage examples

Federated search across multiple services

Drag ARIADNESearch, BodleianSearch, and EuropeanaSearch onto the canvas.
Type a query (e.g. Stonehenge) into the inline query fields on all three nodes.
Connect all three outputs to a single TableOutput node.
Click ▶▶ Run All — results from all three services appear merged in one table.

Browse a IIIF manuscript and annotate regions for inference

Run a BodleianSearch query (e.g. illuminated manuscript).
Connect the output to an ImageView node and switch it to IIIF mode.
Use the From upstream picker to select a manuscript — the manifest loads automatically.
Navigate to a page of interest using the ‹ / › canvas buttons.
Click + Region and drag boxes around specific areas (a decorated initial, a marginal annotation, a seal).
Click Capture 3 — each region is fetched as a base64 JPEG via the IIIF Image API.
Connect the ImageView output handle to a KingsInference node with Vision enabled.
Write a prompt such as "Describe what you see in this region of a medieval manuscript."
Click ▶ Run on KingsInference — each region is analysed individually.
Connect the output to KingsInferenceOutput to browse responses as expandable cards.

Inference on local images

Drag LocalFolderSource → KingsInference → KingsInferenceOutput and connect them.
Click 📂 Pick Folder and select a folder of JPEG or PNG images.
On KingsInference, enter your API key, select a vision-capable model, tick Vision, and write a prompt using {{content}} (or leave it blank to describe the image).
Click ▶ Run on LocalFolderSource, then ▶▶ Run All.

Federated search + Wikidata cross-linking

Run ARIADNESearch and GBIFSearch with overlapping subjects.
Connect both to a Reconciliation node (field title or scientificName, authority: Wikidata Items / Taxa).
Connect Reconciliation to MergeByQID — records that resolved to the same Wikidata entity are merged.
Connect to WikidataEnrich and tick properties of interest.
Connect to TableOutput and enable expand namespaces to see cross-service fields side-by-side.

Offline workshop demo

On each search node, type a query matching a bundled fixture (e.g. stonehenge) and tick 📦.
Click ▶ Load fixture — results load instantly from the repo with no network calls.
For local text analysis, drag a LocalFolderSource onto the canvas and point it at public/fixtures/LLDS Collections/stonehenge.
Connect the XML handle to an XMLExtract node or the main output to KingsInference for AI-assisted analysis.

Web content extraction

Run any source node with _sourceUrl fields.
Add URLContentFetch, select the URL field, and fetch pages.
Add HTMLPreview — click any element in the rendered page to capture its CSS selector.
Add HTMLExtract, paste the captured selector, and extract the section.
Add KingsInferenceByField in per-record mode with fetchedContent and a targeted extraction prompt.

Project structure

nfcs-poc/
├── CLAUDE.md                   # Architecture notes and API references (dev only)
├── vite.config.ts              # Dev server + CORS proxy rules + /url-proxy middleware
├── public/
│   └── fixtures/               # Pre-baked search results + sample collection material
│       ├── README.md
│       ├── *.json              # {nodeType}-{query}.json
│       └── LLDS Collections/
└── src/
    ├── App.tsx                 # Canvas, sidebar, Run All, save/load, node factories
    ├── types/
    │   ├── UnifiedRecord.ts
    │   └── savedSearch.ts
    ├── store/
    │   └── resultsStore.ts     # Out-of-band record store (avoids React state bloat)
    ├── hooks/
    │   └── useUpstreamRecords.ts
    ├── components/
    │   ├── ConnectionSuggestions.tsx   # Context-aware node suggestion popup
    │   └── ChatSidebar.tsx             # KCL Assistant chat panel
    ├── nodes/
    │   ├── index.ts
    │   ├── ParamNode.tsx
    │   ├── CommentNode.tsx
    │   ├── ARIADNESearchNode.tsx
    │   ├── BodleianSearchNode.tsx      # Bodleian Digital Collections
    │   ├── EuropeanaSearchNode.tsx
    │   ├── GBIFSearchNode.tsx
    │   ├── LLDSSearchNode.tsx
    │   ├── MDSSearchNode.tsx
    │   ├── GroupNode.tsx               # Group container node
    │   ├── EvaluatorNode.tsx           # LLM-as-judge evaluation
    │   ├── QuickNoteNode.tsx           # Human annotation and scoring
    │   ├── ComparisonReportNode.tsx    # Comparison report output
    │   ├── LocalFileSourceNode.tsx
    │   ├── LocalFolderSourceNode.tsx
    │   ├── SaveSearchNode.tsx
    │   ├── LoadSavedSearchNode.tsx
    │   ├── FilterTransformNode.tsx
    │   ├── SpatialFilterNode.tsx
    │   ├── FieldDistributionNode.tsx
    │   ├── TimelineOutputNode.tsx      # TimelineView — filter + timeline visualisation
    │   ├── KCLNode.tsx                 # KingsInference — per-record, vision-capable
    │   ├── KCLFieldNode.tsx            # KingsInferenceByField — single-field inference
    │   ├── KCLOutputNode.tsx           # KingsInferenceOutput — card display
    │   ├── ReconciliationNode.tsx
    │   ├── WikidataEnrichNode.tsx
    │   ├── MergeByQIDNode.tsx
    │   ├── OllamaNode.tsx              # (hidden — local Ollama)
    │   ├── OllamaFieldNode.tsx         # (hidden — local Ollama)
    │   ├── OllamaOutputNode.tsx        # (hidden — local Ollama)
    │   ├── URLFetchNode.tsx
    │   ├── HTMLSectionNode.tsx
    │   ├── HTMLPreviewNode.tsx         # WYSIWYG CSS selector capture
    │   ├── XMLSectionNode.tsx
    │   ├── QuickViewNode.tsx
    │   ├── ImageViewNode.tsx           # Images + IIIF + region annotator + output handle
    │   ├── TableOutputNode.tsx
    │   ├── JSONOutputNode.tsx
    │   ├── MapOutputNode.tsx
    │   ├── CitationNode.tsx
    │   ├── ExportNode.tsx
    │   ├── SmartGeocoderNode.tsx       # LLM-assisted place extraction + geocoding
    │   ├── SmartFilterNode.tsx         # Natural-language → structured filter
    │   ├── SourceProfileNode.tsx       # Schema inspector + AI narrative
    │   ├── QuickStartNode.tsx          # AI workflow planner
    │   ├── ReconciledCell.tsx
    │   └── ExpandedOutputPanel.tsx
    └── utils/
        ├── nodeRunners.ts              # Registry: node type → NodeRunner
        ├── runWorkflow.ts              # Topological executor (Kahn's algorithm)
        ├── workflowIO.ts
        ├── nodeIdCounter.ts
        ├── upstreamRecords.ts
        ├── fixtureUtils.ts
        ├── reconciliationService.ts
        ├── filterTransformUtils.ts
        ├── exportUtils.ts
        ├── fileReaders.ts
        ├── citationUtils.ts
        ├── run<Name>Node.ts            # One runner per runnable node type
        └── *Adapter.ts                 # Service-specific response → UnifiedRecord

Adding new nodes

Two developer documents cover extension:

docs/federation-baseline.md — the checklist that makes an external data service a good federation candidate (open API, CORS, PIDs, licence metadata, pagination, field completeness), with GBIF and Europeana scored as worked reference implementations.
docs/context-accrual.md — the design for workflow context accrual: how pipeline history (search terms, services combined, filters, transforms) is derived from the node graph and surfaced to downstream LLM nodes via the {{_lineage}} prompt token (implemented — see Context accrual).

The step-by-step registration checklist for a new node lives in CLAUDE.md. Adapter output is contract-checked by the fixture conformance test suite (npx vitest run); npm run build must stay green.

Tech stack

Library	Purpose
Vite	Dev server, bundler, CORS proxy
React 19 + TypeScript	UI framework
@xyflow/react v12	Node-based canvas
Leaflet	Map rendering (MapOutput, SpatialFilter)
pdfjs-dist	Client-side PDF text extraction
shpjs	Client-side Shapefile parsing
Puppeteer	Headless browser for JS-rendered page fetching
react-markdown + remark-gfm	Markdown + GFM table rendering in the KCL Assistant chat panel
Ollama	Local LLM inference (external; hidden from sidebar)

No backend. No database. No authentication. All API calls are made directly from the browser (or via the Vite dev proxy for services without permissive CORS). For deployed instances, see the deploy/express-server branch.

Name		Name	Last commit message	Last commit date
.claude		.claude
docs		docs
images		images
public		public
server		server
src		src
.dockerignore		.dockerignore
.env.example		.env.example
.gitattributes		.gitattributes
.gitignore		.gitignore
CLAUDE.md		CLAUDE.md
Dockerfile		Dockerfile
README.md		README.md
TODO.md		TODO.md
data_services_summary.txt		data_services_summary.txt
deployment-summary.txt		deployment-summary.txt
docker-compose.yml		docker-compose.yml
index.html		index.html
package-lock.json		package-lock.json
package.json		package.json
robots_txt.txt		robots_txt.txt
tsconfig.app.json		tsconfig.app.json
tsconfig.json		tsconfig.json
tsconfig.node.json		tsconfig.node.json
vite.config.ts		vite.config.ts
workshop-scenarios.pdf		workshop-scenarios.pdf

Uh oh!

Latest commit

History

Folders and files

Repository files navigation

National Federated Compute Services – Arts & Humanities

Video tutorials

Prerequisites

Installation

Saving and loading workflows

Node types

Canvas

Input

Inspection

Data Services

Filters and Transforms

Extraction and Enrichment

Output

Data flow

Execution model

Node grouping

Creating and managing groups

Collapsing and expanding

Auto-grow

Duplicating groups

The UnifiedRecord schema

KCL Inference

Setup

Prompt templates

Vision mode

KingsInferenceByField

Output

Prompt recipes

Context accrual — the {{_lineage}} token

FrameSense workflows

Pre-processing (offline, outside this app)

Using FrameSenseSource in the workflow

Wiring for vision inference

Aggregate summary with KingsInferenceByField

Recommended workflow

Human evaluation and LLM-as-judge

The three roles

Criteria alignment

Running the pipeline

ImageView and IIIF region annotation

Images mode

IIIF mode

Region annotation

Info panel

Filter / Transform

Filter mode

Transform mode

Both mode

Reconciliation

Wikidata enrichment and linking

WikidataEnrich

MergeByQID

SPARQL Search

Live entity and property lookup

✨ NL assist with QID grounding

Endpoints

Wiring and outputs

Worked example

URL fetching and section extraction

URLContentFetch

HTMLExtract

Export

Saved search caching

Workshop deployment and retrieving saves

File naming

Listing saves (without extracting)

Extracting all saves to a local folder

After extraction

Offline fixtures

Bundled fixtures

LLDS collection samples

CORS and the dev proxy

KCL Assistant

What you can ask

Setup

Context accrual — the `{{_lineage}}` token