Building an Ontology-Backed Reporting Workflow

Overview

A recurring reporting process depended on separate emails, files, and manual consolidation at each level. I interviewed users, modeled the workflow in the platform ontology, and built a working application that keeps report creation, submission, review, content selection, and onward reporting in one connected system. The initial version reached real users; an extension to additional organizational levels is now moving into user testing.

Initial Ask

Reduce the time and cognitive effort spent copying, pasting, and manually consolidating recurring reports submitted by email.

Problem

There was no shared workflow for contributors to prepare and submit inputs or for reviewers to evaluate those inputs, select relevant material, and build the next report. Users repeatedly reconstructed the same process through email, files, and manual copy-and-paste.

Desired Outcome

Give contributors and reviewers one understandable workflow that preserves both the current reporting process and the historical record behind it.

Constraints

• Real report contents, detailed organizational reporting chains, source data, access structures, and internal identifiers are intentionally omitted.
• The broader intended user population is not presented as active adoption; the defensible current figure is roughly 10 actual users or testers.
• Time saved, error reduction, and rework reduction have not been measured, so the case does not claim quantitative process improvement.
• The extension to additional organizational levels is still entering user testing and is not described as fully deployed.

Approach

I began with user interviews and mapped the actual handoffs rather than recreating the email process in a new interface. I represented the reporting levels and lifecycle in the ontology, created the actions needed to move reports through that lifecycle, and built the user experience as custom Workshop widgets. The design keeps current work connected to persistent historical records so users can retrieve prior reporting without falling back to shared folders and inbox searches.

Key Decisions

Solution

A Palantir Foundry/Vantage application supporting report creation, editing, deletion, submission, review, selection of relevant subordinate content, and creation of the next report in the reporting chain.

Personal Contribution

I interviewed users, reframed the problem, designed the workflow and ontology, created the report object types and lifecycle actions, and built the Workshop experience as custom TypeScript/React widgets using OSDK. An operations stakeholder provided points of contact and reference information used to establish the base records.

Technical Implementation

The application uses Palantir Foundry/Vantage, Workshop, React, TypeScript, and OSDK. Custom widgets implement the user-facing workflow while ontology-backed records and actions preserve state and history. Exact internal object names, action names, reporting structures, and real report data are intentionally excluded.

Tech Stack

• Palantir Foundry / Vantage
• Workshop
• OSDK
• TypeScript
• React

Result & Impact

• ~10
  Actual users / testers
• Monthly
  Current cadence

The initial version is a working internal tool that has reached operations and leadership users. It began on a weekly cadence during stress testing and later tapered to a monthly reporting cycle. The application removes the need to treat email and manual copy-and-paste as the workflow itself, but time saved, error reduction, and rework reduction have not yet been measured.

Learnings

• The first useful design question was not how to digitize the form; it was how contributors, reviewers, historical records, and onward reporting should relate to one another.
• For recurring operational workflows, preserving historical context can matter as much as automating the current handoff.
• A deployment claim and an impact claim are different things. Real users can validate that a system works before enough evidence exists to quantify the improvement.

Next Steps

• Complete user testing for the extension to additional organizational levels.
• Capture structured user feedback and defensible before-and-after measures if they become available.
• Create a fully synthetic public workflow visual rather than exposing operational screenshots.