What you’ll be able to do after reading this. Recognize the design principles that distinguish a regulator-defensible investigator workflow from a generic data-viewer. Read a Workshop module specification and understand what the analyst sees on screen. Identify the action-design discipline that ties the investigator’s screen activity to the audit-trail apparatus (Foundry Actions Framework). Spot the performance-pattern failure modes that turn a responsive application into a five-million-row crawl. Document a counterparty review in workpapers that satisfy PCAOB AS 2401 §A.5 evidence-organization expectations and FFIEC BSA/AML Customer Due Diligence procedures.
Terms anchored before the article walks them:
- Ontology — structured, typed representation of business entities (Counterparty, Person, SanctionsHit, etc.) with explicit relationships and properties. Articles 001 and 009 in this sub-series walk the ontology pattern in depth.
- Object card — the Workshop UI primitive that renders one ontology object (a single Counterparty, for example) with its linked relationships, summary, and available actions. Conceptually equivalent to a customer file in a case-management system.
- Action — a configured state-change verb (ElevateRiskRating, DismissSanctionsHit, EscalateToEDD). Per Foundry Actions Framework, actions are the audit-defensible boundary; every state change runs through one.
- RBAC (Role-Based Access Control) — the institution’s structured permission system. A user’s RBAC role determines which Workshop modules they can open, which actions they can invoke, and which dual-approval flows they can sign off on.
- AIP (Artificial Intelligence Platform) — Palantir’s bundled LLM-orchestration product. AIP-Driven Adverse-Media Summarization walks the AIP pattern; this article uses it in the in-card summary band.
- EDD (Enhanced Due Diligence) — the heightened-investigation tier above standard customer due diligence, triggered by elevated risk factors. FFIEC BSA/AML Examination Manual defines the regulatory expectation; this article’s EscalateToEDD action is the platform-side trigger.
A Workshop application is the surface where the ontology meets the human investigator. Without it, the ontology is a well-structured dataset with no operational reach. With it, the ontology becomes a workflow — a counterparty card the investigator opens, a transaction graph they navigate, a sanctions hit they escalate, an action they take that becomes a tracked audit-trail event in the sense of Foundry Actions Framework. The design of that Workshop application is what determines whether the institution’s due-diligence analysts can complete a substantive counterparty review in ten minutes or ninety. The eighty-minute difference is not exotic technology; it is the accumulated cost of the investigator switching between five tools to assemble facts that should have been one click away.
This article walks the Workshop patterns that earn their keep in counterparty-risk investigations. The single-pane-of-glass principle that anchors the design. The information-density gradient that puts the right facts at the right depth. The object-card composition that translates ontology structure into investigator-relevant layout. The AIP integration that brings adverse-media synthesis into the card without sacrificing the grounding-and-citation discipline. The action design that ensures every state change runs through the audit-trail apparatus. The performance patterns that keep the application responsive at scale. The cross-counterparty navigation that lets the investigator follow ownership chains and transaction graphs without losing context. And a worked example that puts the patterns together end to end.
The patterns are not Foundry-exclusive in concept — investigator-workflow applications built on Snowflake with Streamlit, Databricks with Lakeview, or custom Vue/React over a warehouse implement the same principles. Foundry vs Snowflake + DBT vs Databricks in this sub-series handles the architecture comparison across platforms. What is Foundry-specific is the implementation pattern, the ontology-aware UI primitives Workshop provides, and the integration with the Actions framework and AIP that the rest of the sub-series builds on.
The single-pane-of-glass principle
Consider what the investigator does in a typical counterparty review without Workshop. They pull the counterparty record from one system. They check the sanctions screening from a separate tool. They open the adverse-media feed in a third browser tab. They reach for a spreadsheet log to see prior rating actions. They drop into a transaction-monitoring system to look at recent volume. They check the beneficial-ownership graph in yet another system. Each context-switch costs thirty to ninety seconds of orientation. For a fifteen-element counterparty review, the context-switching overhead alone is fifteen minutes — before the analyst has done any analytical work at all.
The single-pane-of-glass principle is that the investigator should assemble the relevant facts about one counterparty without leaving one surface. Not because UI consolidation is intrinsically valuable — practitioners who have suffered through bad enterprise UIs know UI consolidation can also be a way to slow everyone down — but because the cognitive cost of context-switching dominates the actual analytical work on most counterparty reviews. Eliminating the cost is what makes the investigator’s time spend on judgment rather than navigation.
The principle has implementation consequences. The Workshop application has to assemble its content from across the ontology — counterparty record, linked sanctions hits, linked adverse-media mentions, linked transactions, linked beneficial-ownership chain, linked prior actions — in a single render. The ontology link structure that the forthcoming Counterparty Ontology Design article introduces becomes the architectural foundation for the application: the application’s primary screen is essentially a navigation of the Counterparty object’s outbound link structure, with each linked object class rendered as a section of the screen.
Information-density design
What goes at the top of the counterparty card, and what goes one click away, is the question that determines whether the investigator can scan a card in thirty seconds versus reading it for two minutes. The answer follows the actual investigator workflow, which has been studied enough across audit and compliance domains to support a useful heuristic.
The top of the card carries the high-frequency, decision-relevant facts. Legal name. Jurisdiction. Current risk rating, with conditional formatting that visually distinguishes a “critical” rating from a “low” one (background color, weight, position). Last KYC refresh date. Active sanctions-hit count. This is the panel the investigator scans in the first three seconds to decide whether the counterparty requires their attention or can move to the next item in the queue.
The second band carries the contextual summary. For institutions with AIP integration, this is where the model-generated risk synthesis lives — a 150-200-word paragraph summarizing recent adverse-media findings, with citation-and-grounding controls per AIP-Driven Adverse-Media Summarization‘s discipline. For institutions without AIP, the same band carries a hand-curated summary the institution maintains through analyst notes, or a “no recent activity” placeholder. The band is one paragraph; it earns its space if and only if the analyst reads it on every review. If the band is wallpaper the analyst scrolls past, it is the wrong content.
Below the summary, the relationship sections give the investigator the structural picture of the counterparty’s links. Top transaction counterparties by volume, with the time-series chart available on hover. Beneficial-ownership chain, with the ownership graph one click away. Active sanctions hits, with the sanctions list full-text available on click. Each section presents the top elements at the surface (top ten transactions, ultimate beneficial owners only, currently-active hits only) and pushes the long tail to a contextual drill-down.
The information-density gradient is, in one sentence: high-frequency facts at the surface, dependent detail one click away, comprehensive views two clicks away. The investigator’s eyes flow naturally from header to summary to relationships, the same pattern they would follow if reading a structured analyst memo about the counterparty. The corollary discipline is that the institution must actually test the layout against real investigator workflow before shipping. The “obvious” layout the engineer designs and the actual layout the investigator uses are not always the same; eye-track sessions with actual analysts on actual cases are what catch the difference.
Object-card composition
Workshop’s primitives for the card itself are bounded: a header section with field grid, a summary section with rich text, repeating relationship sections that render linked object sets, an actions section with the available state-change verbs. The composition decisions the engineer makes are about which sections to include for which counterparty patterns, what to render in each section, and how to handle the conditional layout decisions that real counterparties produce.
A counterparty with no active sanctions hits should not have an empty “Sanctions Hits” section taking up vertical space; the section should be visually de-emphasized or hidden entirely. A counterparty with twenty-three active sanctions hits should not be rendered with all twenty-three at the surface; the surface shows the most recent five and a “view all” affordance reveals the remainder. The engineer’s conditional-layout decisions are the difference between an application that adapts to the actual data and an application that renders a template the data sometimes fits awkwardly into.
The split-pane-versus-tabbed-pane choice is more architectural. Split-pane (the layout the seed describes) puts the object card in the primary pane and a contextual navigator in the secondary pane that updates based on what the investigator selects in the primary pane. Click on the TransactedWith section, the secondary pane shows the transaction-volume time-series chart. Click on a beneficial-ownership entry, the secondary pane shows the ownership graph. The investigator never loses their orientation in the primary pane while exploring details in the secondary pane. Tabbed-pane, by contrast, puts each subsystem (counterparty record, transactions, ownership, sanctions) in a separate tab; the investigator clicks tabs to navigate. Tabs are simpler to build and cheaper at the platform level, but they hide the context the split-pane preserves. For counterparty-risk investigations specifically, the split-pane is usually the right choice because the investigator’s primary work is moving between dimensions of the same counterparty rather than treating each dimension as a separate study.
The companion bundle’s workshop_module/workshop_layout.yaml ships the full split-pane specification implementing the patterns this section describes. The reader can adapt the section list to the institution’s specific ontology — adding fields like principal_industry or country_risk_tier that the institution’s risk-rating framework requires.
AIP integration in the card
When the institution integrates AIP into the Workshop application, the most valuable placement is inline in the object card’s summary band. The investigator does not need to switch to a separate AIP chat surface; the synthesis appears where the rest of the counterparty content appears, with the same scrolling discipline and the same level of trust.
The integration pattern requires the AIP function configured per AIP-Driven Adverse-Media Summarization‘s discipline: a prompt that produces a structured 200-word summary, grounded to specific source documents via the citation_check post-processor, with the hallucination_verifier_llm as the second-stage gate. The Workshop card consumes the AIP function’s output and renders it inline. Critically, the rendering preserves the citations: each factual assertion in the summary text is hover-linked (or tap-linked, in mobile contexts) to the source passage it grounds in. The investigator can verify any claim in the summary without leaving the card.
This is the difference between a Workshop card with a generic chatbot summary and a Workshop card with a regulator-defensible AIP output. The chatbot summary may say “the counterparty has been reported in recent adverse media.” The AIP-grounded summary says the same thing but with three citations linking to specific source articles dated within the last ninety days. The first version, the investigator has to verify externally. The second version, the investigator verifies inline.
The integration pattern also handles the failure modes the AIP function produces. When insufficient_corpus is true (per AIP-Driven Adverse-Media Summarization‘s schema), the summary band renders an explicit “Adverse-media corpus too thin for AIP synthesis; manual review required” rather than a generic empty state. The pattern matters because empty-state confusion produces the worst kind of failure mode — the investigator does not know whether the absence of summary content means “nothing to summarize” or “the system has an issue.” The explicit insufficient-corpus state eliminates the ambiguity.
Action design
The disciplined version of the Workshop application makes actions the only way investigators change ontology state. The investigator does not edit fields directly. They do not click into a row and type a new value. They invoke an action — ElevateRiskRating, DismissSanctionsHit, EscalateToEDD, EscalateToEDD — and the action runs through the Actions framework (Foundry Actions Framework) for audit-trail compliance.
Actions are the audit-defensible state-change boundary, and the Workshop application’s job is to make them feel as natural to invoke as field edits would have felt. The action card pops over the primary pane. Required fields (the new rating value, the justification text, the supporting-evidence ObjectSet) are surfaced clearly. Conditional logic in the action’s authorization (per Foundry Actions Framework‘s dual-approval pattern) is visible — the investigator sees “this action requires compliance-manager approval” before they submit. The audit-trail entry that the action produces is referenced inline after submission, so the investigator can confirm the action recorded what they intended.
Visibility rules on the action set matter as much as the action mechanics. An ElevateRiskRating action is visible only when the counterparty’s current rating allows elevation (visible for low and medium, hidden for critical — there is no rating above critical). An EscalateToEDD action is visible only when at least one section of the card is flagged for review. The visibility rules translate the institution’s workflow policy into UI-level guardrails. The discipline is to encode the policy in the action visibility, not in analyst memory or in a written procedure that goes unread.
The frequent failure mode this section deserves frank treatment for: applications that bypass the Actions framework with “quick edits” to fields. A field that can be edited directly produces no AuditEntry. A field that can only be changed through an action produces a complete audit chain. The institutional discipline is to forbid direct field edits on regulated ontology objects. Workshop’s design should make this discipline easy: the field is rendered, but not editable; the affordance for changing it is the action that runs through the Actions framework. The seemingly minor UX choice carries the audit-trail implication that distinguishes a regulated investigator surface from a generic data viewer.
Performance patterns
A Workshop application that renders in ten seconds on a development environment with ten thousand counterparties may render in two minutes on production with five million. The performance patterns that keep the application responsive at scale fall into a small set that the engineer should plan for from the first prototype rather than discover under production load.
Search-index strategy on the underlying ontology. Workshop’s object-card rendering is driven by ontology lookups. Counterparty fields the application surfaces — legal_name, jurisdiction, risk_rating, last_kyc_refresh — should be indexed in the ontology layer for fast lookup. The institution’s deployment configuration controls which fields get indexed; the engineer specifies the indexing requirement based on the actual surface design. Fields the application surfaces in headers or filters must be indexed; fields the application only renders in click-through detail can use the default index strategy.
Object-set pagination. A counterparty with five thousand transactions should not render five thousand transactions inline. The TransactedWith section renders the top ten by volume at the surface, with “view all” loading the remainder in a paginated view. The pattern is straightforward; the failure mode is the engineer who forgets to apply it and ships an application that hangs the browser on high-activity counterparties.
Contextual-navigator lazy loading. The secondary pane in the split-pane layout should not pre-render every possible contextual view. The transaction-volume time-series chart loads when the investigator clicks the TransactedWith section, not when the card itself renders. The ownership-graph visualization loads on click, not on mount. The pattern is the same as any modern web application’s tab-loading discipline: render what is visible, defer what is hidden.
Time-series chart aggregation. A two-year transaction-volume chart at daily resolution is seven hundred and thirty data points per series. Multiple series compound the count; rendering thirty thousand data points in a Workshop chart is the SVG-renderer’s death by paper cut. The pattern is to aggregate at the server side: daily for the most recent ninety days, weekly for the prior twelve months, monthly beyond that. The investigator’s eye does not benefit from the higher resolution at depth; the browser benefits substantially from the lower point count.
Concurrent-user testing. Workshop applications run multi-tenant. An application that performs well for one user may perform poorly for twenty users simultaneously hitting the same ontology partitions. The institution’s pre-production testing should include concurrent-user simulation at the realistic concurrency target. The most common failure mode is the application that ships at single-user-tested performance and then degrades sharply under realistic load.
Cross-counterparty navigation
Investigations rarely stay on a single counterparty. The investigator opens counterparty A, sees a beneficial-ownership link to counterparty B, navigates to B to check its history, sees a transaction link to C, navigates to C, and so on. The Workshop application’s navigation pattern between counterparties determines whether this exploration feels natural or feels like fighting the tool.
The well-designed pattern is that every linked counterparty in the primary pane is a one-click navigation to that counterparty’s card. The new card replaces the current card, but the investigator’s path is preserved in a breadcrumb trail so they can return to the original counterparty. The contextual-navigator pane preserves its state where appropriate (the transaction-volume chart for counterparty A doesn’t survive a navigation to counterparty B, but a “compare to counterparty A” option becomes available on counterparty B’s transaction section). The navigation is fast because the underlying ontology lookups are indexed for exactly this case.
The pattern that does not work is treating each counterparty as a separate full page load. The investigator who navigates across five counterparties in a chain experiences five full reloads; the cumulative wait time turns ten minutes of analytical work into thirty. The Workshop application’s responsibility is to keep the chain-following feel as fast as the within-card exploration feels.
Worked example
Consider a counterparty-risk-investigation module built end to end against a synthetic five-thousand-counterparty ontology — the same scale Codex’s companion bundle for Workshop Application Patterns ships. The module follows the patterns this article walks: split-pane layout, header band with conditional formatting on risk rating, AIP-grounded summary band with citations to the linked AdverseMediaMention objects, relationship sections for TransactedWith, UltimateBeneficialOwner, and SanctionsHit, action set including ElevateRiskRating with visibility conditioned on current rating and EscalateToEDD with visibility conditioned on any-section-flagged status.
The investigator opens the module on counterparty CP-SYNTH-00042. The header renders with the counterparty’s legal name, Singapore jurisdiction, current risk rating “high,” last KYC refresh six months prior. The AIP summary band renders a 180-word synthesis citing four adverse-media items from the prior ninety days, each citation hover-linked to the underlying source passage. The TransactedWith section surfaces the top ten counterparties by transaction volume; clicking the section header loads the time-series chart in the secondary pane showing transaction volume over the last 730 days at appropriate aggregation. The UltimateBeneficialOwner section shows the resolved beneficial owners; clicking surfaces the ownership graph. The SanctionsHit section shows one active hit; clicking surfaces the sanctions-list full text in the secondary pane.
The investigator reviews the surface, concludes the counterparty warrants escalation, clicks the EscalateToEDD action. The action card pops over the primary pane. The required fields prompt for justification text (minimum 200 characters per the Foundry Actions Framework floor) and supporting-evidence ObjectSet. The investigator selects the four AdverseMediaMention objects and the one SanctionsHit object as supporting evidence and writes a 450-character justification citing the specific pattern: the four media items concentrated in the prior 90 days, the active sanctions hit, the absence of countervailing factors in the counterparty’s recent KYC refresh.
The investigator submits. The Action framework validates: the analyst’s role meets the authorization level, the justification length meets the minimum, the supporting-evidence set is non-empty and contains allowed types. Validation passes. The side effects fire. A new EDDEngagement ontology object is created linked to the counterparty. An AuditEntry is created capturing the action’s full lineage. The post-execution hook routes the counterparty into the EDD queue for the compliance team’s review.
The investigator’s elapsed time from opening the module to submitting the action: eight minutes. Without the single-pane-of-glass surface, the same review would have spanned five tools, fifteen-plus context-switches, and probably forty-five minutes — most of which would not have been analytical work.
The companion bundle’s workshop_module/workshop_layout.yaml ships the YAML for the module. The synthetic_data/counterparties.csv (5,001 rows), relationships.csv (10,006 rows), and time_series_metrics.csv (601 rows) ship the synthetic ontology — generated deterministically by tools/generate_counterparty_demo_data.py. The screenshot_equivalents.md describes the rendered surfaces in prose for readers without access to a live Foundry instance. The reader who works through the bundle end-to-end can reconstruct the same investigator surface on their own deployment, adapting the counterparty fields and ontology relationships to their institution’s structure.
A grounding case: when investigator-workflow design becomes the finding
The institutional history of regulatory enforcement includes cases where investigator-workflow fragmentation appeared as a contributing factor to the underlying compliance failure. The HSBC USA AML enforcement action (DOJ deferred prosecution agreement 2012, FinCEN Consent Order, OCC Consent Order — $1.9B total settlement) included as one finding among many that the institution’s transaction-monitoring analysts worked across multiple disconnected systems to investigate flagged transactions, with the friction of system-switching contributing to investigation backlog and missed escalations. The Foundry Workshop pattern this article walks — single-pane-of-glass with all linked evidence one click away — directly addresses the failure mode HSBC’s monitoring environment exhibited.
The Danske Bank Estonia branch matter (Estonian Financial Supervisory Authority 2018, US DOJ guilty plea 2022, OFAC settlement 2024) similarly involved investigation-workflow constraints contributing to the multi-year window in which suspicious transactions accumulated. The analyst surface that supports rapid evidence assembly — the kind of object card this article walks — is the operational discipline that lets human judgment scale across the volume institutional AML programs face.
What the practitioner does with these references. When evaluating an investigator-workflow application (either advocating for one, operating within one, or reviewing one in audit), ground the evaluation in regulator-facing consequence: does the workflow let an analyst complete a substantive Customer Due Diligence review in operationally sustainable time, and does the application produce the evidence chain (per Foundry Actions Framework‘s AuditEntry structure plus the supporting-evidence snapshots) that the examiner asks for? The companion bundle’s workshop_module/workshop_layout.yaml is the platform-side configuration; the institutional discipline that makes the configuration produce examination-credible work is consistent analyst training, action-design hygiene, and bypass-control enforcement (Foundry Actions Framework‘s framework).
Authority
- Palantir Foundry Documentation — Workshop (modules, layouts, object cards, actions, time-series widgets).
- Palantir AIP Documentation — Integration within Workshop (grounding, citations, output validation).
- Federal Financial Institutions Examination Council, BSA/AML Examination Manual, on investigator workflow expectations.
- PCAOB Auditing Standard AS 2401, Consideration of Fraud in a Financial Statement Audit, particularly §A.5 on documentation of audit evidence.
- Tognazzini, B. (2014). First Principles of Interaction Design. For the information-density gradient and eye-track-expectation framing.
- Wickens, C.D., Hollands, J.G., Banbury, S., & Parasuraman, R. (2015). Engineering Psychology and Human Performance (4th ed.). Routledge. For the cognitive-load considerations in high-information-density UIs.
- Cooper, A., Reimann, R., Cronin, D., & Noessel, C. (2014). About Face: The Essentials of Interaction Design (4th ed.). Wiley. For the action-design framing distinguishing edits from state-change events.
Companion repository
Workshop Application Patterns‘s full companion bundle lives at github.com/noahrgreen/dd-tech-lab-companion/articles/003_workshop_application_patterns_investigators/. It ships the Workshop module specification, the synthetic 5,000-counterparty ontology (synthetic_data/counterparties.csv, relationships.csv, time_series_metrics.csv), the action-template definitions, the deterministic data-generator script, and the markdown screenshot-equivalents for readers without access to a live Workshop instance. AIP-Driven Adverse-Media Summarization covers the AIP integration that powers the in-card risk summary; Foundry Actions Framework covers the Actions framework that handles every state change the module surfaces.