Sheepdog Prosperity Partners
Due Diligence

Quiver for Ad-Hoc Counterparty Queries: Lightweight Investigator Tooling Without a Full Workshop Build

by | May 15, 2026 | DD Tech Lab | 0 comments

What you’ll be able to do after reading this. Recognize the situations where Quiver is the right tool and where Workshop is. Read a saved Quiver query specification and understand what it returns. Apply a seven-criterion graduation checklist to decide when a recurring Quiver query should become a Workshop application. Distinguish what Quiver activity logs capture from what AuditEntry records capture (Foundry Actions Framework). Document Quiver-driven investigations in workpapers that satisfy SR 11-7 §V documentation expectations and FFIEC BSA/AML Customer Due Diligence procedures.

Terms anchored before the article walks them, because they appear throughout:

  • Ontology object class — a category of business entity (Counterparty, Person, AdverseMediaMention, AuditEntry) with defined fields and relationships. Quiver queries always target a specific object class.
  • Parameterized query — a saved query where some filter values are placeholders the analyst fills in at run time. Functionally equivalent to a saved Excel template where a few cells are inputs.
  • RBAC (Role-Based Access Control) — the institution’s structured permission system. A user’s RBAC role determines which datasets, queries, and actions they can access. For the practitioner, RBAC is the platform-level enforcement of the institution’s “who is allowed to see what” policy.
  • AuditEntry — the immutable state-change record produced by an action (per Foundry Actions Framework). Reading AuditEntry records is exactly the kind of investigative query Quiver supports natively; Quiver itself does not create AuditEntries.
  • Share-link mechanic — Quiver’s pattern for sharing a saved query with another user with read-only permission; analogous to sharing a Tableau dashboard URL with view-only access.

A Workshop application — the topic of Workshop Application Patterns — is the right tool when the investigator workflow is well-defined, repeated across many counterparties, and worth the engineering investment to scaffold. Quiver is the right tool when the question is one-off. A news event just dropped naming a specific issuer and the analyst needs to know in the next fifteen minutes which counterparties have direct or indirect exposure. A regulator just sent a list of sanctioned entities and the team needs to scan the portfolio for any matches. A strategy meeting just asked how many counterparties hold the institution’s top decile of adverse-media density this quarter.

These workflows do not justify a Workshop application. They justify a query. Quiver is Foundry’s primitive for that case. The article that follows walks the patterns that serve those workflows, the graduation criteria that signal when a recurring Quiver query has earned promotion to a proper Workshop application, the audit considerations that distinguish Quiver activity from the AuditEntry chain (Foundry Actions Framework), and the worked example showing a Quiver query through its full lifecycle. Quiver is intentionally lightweight; that is its product positioning, not a limitation. The skill the practitioner builds is knowing when each tool fits.

The Workshop-versus-Quiver decision

The cost of choosing the wrong tool runs in both directions, and the framings are usefully asymmetric.

Building a Workshop application that should have been a Quiver query produces engineering investment — typically one to three sprints — for a workflow the team may abandon in two months. It also produces a maintenance burden: the application’s ontology dependencies propagate when the underlying schema changes, and somebody has to keep it working. And it produces permission complexity: Workshop’s RBAC model carries more weight than Quiver’s share-link mechanic, which means the application needs to be wired into the institution’s broader access-management process.

Keeping a Quiver query that should be a Workshop application produces a different set of failure modes. Analysts re-run the same query manually instead of having it baked into a UI surface that handles parameter selection, default filters, and result interpretation. They re-apply contextual knowledge each time, often inconsistently. The audit-trail picture fragments because state-change actions don’t fire from Quiver (only from Workshop applications with Actions framework wiring), and the workflow’s evidentiary chain becomes harder to reconstruct under examination. The Quiver query also hits index-query limits at some point, and analysts route around the limit with manual Excel exports — which is its own failure mode, particularly in regulated workflows.

The graduation criteria the rest of this article walks are the objective self-assessment that helps the institution decide. Most workflows clearly belong on one side or the other; the gray-zone workflows are where having a checklist matters most.

Instant-query mode: the under-five-minute workflow

Quiver’s entry point is instant-query mode. The analyst opens Quiver, selects a target ontology object class (Counterparty, AuditEntry, AdverseMediaMention, whichever is the unit the question is about), applies filters from a structured filter UI, optionally aggregates and groups, and chooses a visualization primitive. The query runs against Foundry’s indexed ontology, returns in seconds for typical-scale workloads, and renders the result inline.

The mental model an experienced Quiver user develops is that the platform’s ontology is already indexed for typical investigator filters. Counterparty.risk_rating, Counterparty.jurisdiction, AdverseMediaMention.mention_date, SanctionsHit.effective_date — these are index-fast. Filters on these dimensions return results in single-digit seconds even at portfolio scales of hundreds of thousands of objects. Filters that require joining across ontology objects (counterparties linked to specific issuers, counterparties sharing beneficial owners with sanctioned entities) take longer; the article’s performance section walks where these limits actually sit.

The worked-example query in the companion bundle’s query_pack/quiver_counterparty_queries.yaml shows the structure. Here is the annotated YAML for the canonical “news event just dropped, who’s exposed” pattern, exactly as a practitioner would read it before running:

- name: counterparty_exposure_to_issuer
  description: |
    Returns counterparties with direct transaction exposure to a named
    issuer above a USD threshold, grouped by jurisdiction.

  # Which ontology object class to query against. Counterparty is indexed
  # for fast filter/aggregation; the standard target for portfolio scans.
  target_object_class: Counterparty

  # Filters narrow the result set BEFORE aggregation runs.
  filters:
    - has_link: TransactedWith                           # has at least one TransactedWith relationship
    - link_target.issuer_id == :issuer_id_parameter      # the partner equals the issuer at run time
    - TransactedWith.volume_usd >= :min_volume_parameter # only material-volume relationships

  aggregations:
    - count: counterparties             # how many counterparties met the filter
    - sum: TransactedWith.volume_usd    # total exposure in USD
    - group_by: jurisdiction            # group results by counterparty's jurisdiction

  visualization:
    primary: bar_chart
    data_table:
      columns:                          # row-level detail beneath the chart
        - counterparty_id
        - legal_name
        - jurisdiction
        - total_volume_usd
        - last_transaction_date
      sort: total_volume_usd_desc

  parameters:                           # the analyst fills these at run time
    - name: issuer_id_parameter
      type: string
      prompt: "Issuer ID to scan exposure for"
      validation: non_empty             # platform rejects empty submission
    - name: min_volume_parameter
      type: number
      default: 100000                   # $100K default for material-volume screens
      prompt: "Minimum USD exposure threshold"
      validation: positive_number

  share_link_default_permission: read_only

A practitioner reads this in roughly two minutes and knows exactly what the saved query does, what inputs it expects, and what output it produces. That readability — the YAML is the saved-query specification, not a programming abstraction — is what makes the Quiver pattern accessible to credentialed analysts whose primary tool background is Excel rather than SQL. What the practitioner does with this query: when the named issuer becomes regulatorily relevant (sanctions designation, enforcement-action filing, adverse-media spike), the analyst runs the saved query with the issuer ID and the institution’s material-volume threshold, exports the result to a CSV, and attaches the CSV plus the query specification to the case workpaper. The query specification — the YAML above — is itself part of the evidence chain: it documents the parameters that produced the result.

Five queries cover the patterns most institutions need:

The first, counterparty_exposure_to_issuer, returns counterparties with direct transaction exposure to a named issuer above a USD threshold, grouped by jurisdiction with rollups. The query takes two parameters (issuer ID, minimum volume) and produces a bar chart by jurisdiction plus a data table sorted by total exposure descending. This is the canonical “news event just dropped — who’s exposed” query.

The second, sanctions_overlap_via_beneficial_owner, returns counterparties sharing a beneficial owner with any currently-active sanctions hit. The query joins Counterparty to BeneficialOwner to SanctionsHit through the ontology link structure, producing a data table plus a network diagram. The query is heavier than the exposure query because the beneficial-ownership joins are deeper.

The third, adverse_media_density_quantile_screen, returns counterparties in the top-quantile of adverse-media mention density over a 90-day lookback. The parameter is the quantile threshold (default 0.9 = top 10%). Output is a data table plus a histogram with the threshold overlay.

The fourth, rating_change_volume_by_analyst, cross-references Foundry Actions Framework‘s AuditEntry ontology object. It aggregates rating-change actions by analyst over a window, producing a bar chart and a table — useful for institutional self-assessment and for the segregation-of-duties anomaly screening described in Foundry Actions Framework‘s examiner-ready queries.

The fifth, portfolio_risk_distribution, is the strategy-meeting view: counterparty count by risk rating and jurisdiction, rendered as a heatmap.

Each query specifies its visualization primary and secondary, its parameter set with types and defaults, its expected runtime envelope, and its large-universe caveat. The query pack is the operational onramp for a team starting from a blank Quiver workspace.

Parameterized queries and the share-link mechanic

The instant query becomes a saved query when the analyst names it, parameterizes its filter values, and chooses a share-link permission. Quiver’s parameter declaration is structurally similar to a function signature: a name, a type, a default value, a prompt the analyst sees when running, and a validation rule. The framework enforces parameter validation at run time. An analyst who tries to run adverse_media_density_quantile_screen with quantile_threshold = 1.5 gets a validation error, not a silently-empty result.

The share-link mechanic is what makes Quiver scale beyond the individual analyst. A senior analyst constructs a query, parameterizes it, and shares the link with a junior team member. The junior team member can run the query with different parameter values, export the results, and use the data — but cannot modify the saved query and cannot change the underlying ontology data. The permission is read-only by default; the senior analyst would have to explicitly grant edit access if collaborative iteration was the goal.

For team workflows that re-run the same query weekly or monthly, the share-link pattern works. For team workflows that require coordination — review queues, state-change handoffs, evidence-collection chains — the share-link pattern doesn’t, and graduation to a Workshop application is the right move. The graduation-criteria checklist makes the boundary objective.

Visualization primitives: choosing the right one

Quiver’s visualization primitives are intentionally bounded. The five canonical primitives — bar chart, line chart, data table, heatmap, network diagram — cover the substantial majority of investigator queries. Custom visualization is a Workshop concern, not a Quiver concern.

The matching of question shape to visualization primitive is most of the skill. A question about volume by category (how many counterparties exposed to issuer X, by jurisdiction) maps to a bar chart. A question about volume over time (rating-change rate by month, last year) maps to a line chart. A question whose primary output is row-level detail (the actual list of flagged counterparties with their attributes) maps to a data table. A question about a cross-tabulation of two categorical dimensions (counterparty count by risk_rating and jurisdiction) maps to a heatmap. A question about relationship structure (which counterparties share beneficial owners with sanctioned entities, and through what chain) maps to a network diagram.

The failure mode the experienced Quiver user has seen most often is the bar-chart-everything reflex: every aggregate question gets rendered as a bar chart even when the underlying structure is a network or a cross-tab. The result is a chart that’s technically correct but communicatively poor, because the visualization shape doesn’t match the question shape. The remedy is to spend the thirty seconds before clicking “render” considering what the answer actually looks like.

Performance under large object sets

Quiver’s query path uses Foundry’s ontology indexing, which is fast for typical investigator workloads and degrades in predictable ways at scale.

The typical-runtime envelope for the five queries in the companion bundle’s pack: between one and eight seconds, depending on join depth and result-set size. The exposure-to-issuer query typically runs in two to five seconds against a counterparty universe of a hundred thousand to several hundred thousand. The beneficial-ownership join runs three to eight seconds. The quantile-screen and portfolio-distribution queries, which don’t join across ontology objects, typically run in one to three seconds.

At what scale does Quiver hit its limits? Empirically, the boundary appears around one million counterparties for queries that touch all of them, and around five hundred thousand counterparties for queries that join across two or more ontology objects. Beyond those scales, queries time out or produce results too large for Quiver’s rendering layer to handle gracefully.

The mitigation pattern is materialization. Build a Pipeline Builder transform (or a Code Repository transform per Code Repositories in Foundry) that pre-computes the rollups Quiver would otherwise compute on the fly. Issuer-exposure totals per counterparty per quarter, beneficial-ownership-network distance to active sanctions hits, adverse-media density percentiles — each can be a materialized dataset the Quiver query reads from rather than computing live. The trade-off is the freshness of the result: the materialization is as fresh as the pipeline’s last run.

For workflows where freshness matters more than scale (the news event just dropped, the analyst needs an answer now even if the result is approximate), running the live query against a smaller scoped slice — counterparties in specific jurisdictions, or in specific industry segments — is the alternative pattern. The institution’s Workshop applications (Workshop Application Patterns) typically combine both: materialized rollups for portfolio-level views, live queries for case-level drilldowns.

Graduation criteria: when Quiver becomes Workshop

The companion bundle ships a seven-criterion checklist for promoting recurring Quiver queries to Workshop applications. The threshold is four-of-seven: if at least four criteria are met, the workflow has earned promotion.

The criteria are: (1) the query runs at daily or weekly cadence — not monthly or quarterly; (2) five or more distinct users run it regularly — not one or two; (3) results require analyst state-change Actions (the workflow involves not just looking, but acting); (4) analysts run two or more queries in sequence to piece together the answer — the chained-query pattern that benefits from Workshop’s joined-views and persistent state; (5) the visualization requirements exceed Quiver’s bounded primitives — custom entity-relationship network with custom node decorations, time-series with markers, geo-map with custom layers; (6) the query’s output is part of the institution’s evidentiary record (cited in a SAR filing, in a board pack, in a regulatory submission); (7) performance has crossed into materialization-required territory — query times out without rollups, or result sets need pagination Quiver can’t handle.

Most workflows that promote score five or six. Workflows that score two or three usually stay in Quiver. Workflows that score four are the genuine judgment calls; running the checklist on a real query the team uses for several weeks usually clarifies which direction to go.

The cost-of-getting-it-wrong analysis in the companion bundle’s checklist deserves a brief mention. Building a Workshop application that should have been a Quiver query costs engineering time and ongoing maintenance. Keeping a Quiver query that should be a Workshop application costs analyst time on every re-run and creates an audit gap because state-change actions don’t fire from Quiver. The asymmetry matters: engineering time is concentrated and visible; analyst-time-on-Quiver-reruns is diffuse and invisible. Workflows that should have graduated often persist longer than they should because the cost is hidden.

Audit considerations: what Quiver activity captures and what it doesn’t

Quiver queries are read-only investigation activity. They produce analyst activity logs, not AuditEntry objects in the Foundry Actions Framework sense. The distinction has real implications for the audit-trail discipline.

The platform-side activity log records query name, parameters at execution time, executing user, timestamp, result row count, and share-link generation events. This activity log lives in the platform’s audit-and-monitoring layer and is typically retained per the institution’s standard activity-log policy — 180 days to one year is common, though institutional policy may extend.

What the activity log does NOT capture is the specific rows returned by the query. The underlying ontology data may change between query executions. Quiver does not snapshot what the analyst actually saw at the moment of the query. The activity log also does not capture the analyst’s interpretation of the result, or the downstream decision triggered by the query.

The implication for the audit-trail discipline is concrete. When an examiner asks “what investigation occurred between the analyst becoming aware of issuer X’s news event on April 12 and the rating elevation on April 15?”, the answer combines three sources: the AuditEntry for the rating elevation itself (Foundry Actions Framework), with timestamps, actor, justification, supporting evidence; the Quiver activity log, showing which queries the analyst ran with what parameters and when; and the analyst’s narrative interpretation, captured in the justification text on the AuditEntry. Either source alone is insufficient. The combination is what regulators expect.

The failure mode the institution should design controls around is treating a Quiver query result as sufficient documentation in itself. A screenshot of a Quiver query result is not an AuditEntry. If the analyst’s decision relied on the query result, the result must be captured as a supporting-evidence object — snapshotted via the ActionType’s supporting_evidence_snapshot_uri field — and referenced in the AuditEntry’s justification text. Screenshots pasted into informal documentation (email, Word doc, ticket) are exactly the fragmented-audit-trail failure mode the Actions framework exists to eliminate. The analyst’s discipline is to use Quiver to form the judgment, and use the Actions framework to record it.

Mapping to specific regulatory expectations: SR 11-7 §V (Federal Reserve, Supervisory Guidance on Model Risk Management) is about documentation sufficiency. Quiver activity logs contribute to the documentation chain but are not sufficient alone. The AuditEntry’s justification text and supporting-evidence snapshot URIs are the load-bearing artifacts. The FFIEC BSA/AML Examination Manual expects that investigations preceding CDD/EDD decisions be reconstructable. The combined Quiver + AuditEntry record is the answer. PCAOB AS 2201 (for SOX §404 internal-controls testing) samples from AuditEntry populations; Quiver activity is corroborating, not primary.

Worked example: counterparty exposure to a sanctioned issuer

Consider an institution running its standard adverse-media review when a 2024-style enforcement-action news event drops — a regulator announces sanctions against a previously-obscure issuer. The institution’s analyst, alerted via the daily news ingestion pipeline, needs to know which counterparties have direct or indirect exposure within the next fifteen minutes.

The analyst opens Quiver, selects the saved counterparty_exposure_to_issuer query, enters the issuer ID, sets the minimum volume threshold to $100,000, and runs. The query returns in 4.1 seconds with eighteen counterparties exposed, ranked by total volume descending, grouped on the bar chart by jurisdiction.

The analyst scans the bar chart. Six counterparties are in Singapore, four in the UK, three in the US, two in Germany, two in Switzerland, one in the Cayman Islands. The data table shows the top exposed counterparty (CP-SYNTH-00042, $4.2M) is one the institution has been monitoring under heightened review since a prior adverse-media event in April. Three of the eighteen are flagged in the EDD queue already.

The analyst exports the result, shares the saved query link with the senior compliance officer and the geographic team leads, and pivots to the workflow that actually generates state changes — for each of the eighteen counterparties, an EscalateToEDD action (per Foundry Actions Framework) where the supporting evidence includes both the regulator’s sanctions announcement and the Quiver query result snapshotted at the moment of escalation. The Quiver query’s value was in the investigation phase; the recording phase happens in the Actions framework, where the audit trail lives.

Over the following weeks, the same query gets re-run by the same six team members repeatedly as the regulator publishes additional sanctioned entities. The graduation-criteria checklist starts to score higher: daily cadence (criterion 1), five-plus users (criterion 2), audit significance because the query outputs are cited in SAR filings (criterion 6). After three weeks of sustained use, the institution decides the workflow has earned promotion. The Workshop team builds an investigator-facing application around the underlying ontology join, with persistent state for the institution’s ongoing list of monitored issuers, automated daily refresh, and direct integration with the Actions framework for the resulting state changes. The original Quiver query is retired as the Workshop application goes live.

This is what the Quiver-to-Workshop lifecycle looks like in practice. Quiver served the early phase well. The graduation pattern made the transition objective rather than personal preference. The Actions framework caught the resulting state changes regardless of which surface the analyst worked from.

A grounding case: rapid ad-hoc querying as missed-signal recovery

The institutional history of fraud and sanctions cases includes recurrent patterns where rapid ad-hoc querying would have surfaced exposure earlier than the institution did. The Wirecard AG collapse (Munich I District Court 2020-2024 proceedings, Bundesgerichtshof appellate review pending as of 2026) became one of the largest European accounting frauds in part because correspondent banks holding exposure to Wirecard’s third-party-acquiring partner relationships did not run portfolio-scan queries against the network of named partner entities once whistleblower reporting began. The Wirecard issuer relationships were knowable from public filings; the exposure analysis required someone to ask “which of our counterparties has direct or indirect exposure to this issuer,” run that query, and act on it. Many banks ran the query only after the EY audit qualification became public, by which point the analytical value of the early-warning surface had collapsed.

The FTC v. RCG Advances and Yellowstone Capital matter (SDNY 2020, settlement 2023) is a smaller analog. The merchant-cash-advance industry had network exposure to the named defendants through correspondent and processing relationships; institutions with structured ontology-aware query tools could scan their portfolio against the FTC complaint’s named entities the day the complaint dropped. Institutions without those tools waited weeks for manual reviews to assemble the same exposure picture, by which point counterparties had moved funds.

What the practitioner does with these references. The Quiver pattern is operationally valuable only if the analyst maintains the discipline of running portfolio scans against new regulatorily-relevant entities the same day the regulator publishes. The saved query specifications in query_pack/quiver_counterparty_queries.yaml are the operational primitives; the institutional discipline that turns them into examination-credible work is running them on a defined cadence (typically daily for sanctions lists, weekly for adverse-media density, on-event for enforcement actions). The workpaper that documents the institution’s adverse-media monitoring should reference the specific queries run, the dates of execution, the parameters used, and the resulting AlertEntries (per Time Series in Foundry) or AuditEntries (per Foundry Actions Framework) the queries triggered.

Authority

Companion repository

Quiver for Ad-Hoc Counterparty Queries‘s full companion bundle lives at github.com/noahrgreen/dd-tech-lab-companion/articles/007_quiver_ad_hoc_counterparty_queries/. It ships the five-query pack, the seven-criterion graduation checklist with the cost-of-getting-it-wrong analysis, the audit-considerations regulatory mapping, and the screen-equivalent renderings of Quiver’s Instant-Query Mode, Save-As-Parameterized, Share Link, and Graduation Self-Assessment surfaces. Time Series in Foundry covers Time Series in Foundry — the framework for counterparty risk trajectories that often surface first as Quiver queries before graduating to Workshop applications with proper trajectory visualizations.

Submit a Comment

Your email address will not be published. Required fields are marked *