← Priyatham Chimmani

Verifiable artifacts

Foundry-style builds on public data

Foundry is Palantir's data platform. Its core ideas are an ontology of typed objects, links between them, functions and actions on those objects, lineage from source data, and analysis views. This page lists six builds that apply those ideas in plain Python, JavaScript and static HTML, on public data only. For each one it names the Foundry concept it mirrors, the files in the repository, the live page if there is one, and what it does not do.

Non-affiliation. These builds are independent. They are not made by, affiliated with or endorsed by Palantir. They were built without a Foundry account or Foundry code, and they use no employer data: only public OSHA, EPA and CSB records and each repository's own committed outputs. "Foundry-style" describes the pattern, not compatibility; none of this runs in Foundry or imports from it.

How to checkEvery repository path below is a link to the file on the main branch. A test in this site's repository, run in CI and weekly, fetches each linked file and fails if one is missing, and also fails if a number quoted on this page is no longer in the document it comes from. See tests/test_foundry_style.py.

1. OSHA ITA ontology

Seven object types (Establishment, Filing, ReportingYear, Sector, Industry, PeerGroup, QualityFlag) defined in one JSON spec, with links, five functions that call the existing pipeline modules instead of re-implementing rates, and four actions (flag a filing, clear a flag, exclude from the benchmark, restore) that write to editable properties and append to an action log with before and after values. Backing data is the committed outputs/tables/*.csv plus a synthetic fixture; every object carries a source property.

Mirrors
Ontology, object types, link types, object sets and Search Around, functions, action types with submission criteria, writeback, action log, export to downstream datasets.
Repo paths
Live page
None. The artifact is code and a markdown doc in the repository.
Limits
With the default fixture, Establishment and Filing objects are synthetic, so no number computed from them is a finding. The store is in memory and has been run on the fixture only; it has not been run on the full real panel of 2,801,064 filings because the raw files are not in the repository. There is no user or permission model: the actor is whatever string the caller passes.

2. Generated typed client

A generator reads the same spec.json and writes a committed client.py: object types become frozen dataclasses, links become methods that return typed object sets, and actions become methods whose arguments are the action parameters, with Literal types where the spec lists allowed values. A --check mode exits 1 when the committed file no longer matches the spec, and a test runs the same comparison.

Mirrors
Ontology SDK: typed object classes, link traversal methods and action methods generated from the ontology definition.
Repo paths
Live page
None. The artifact is code and a markdown doc in the repository.
Limits
Functions are not generated; they stay in functions.py. It is a pattern-level imitation of an ontology SDK for plain Python, not Foundry's generator, and it inherits the in-memory and fixture-only limits of the ontology above.

3. Filing checker (F1)

A page that checks one Form 300A filing against the project's plausibility screen in the browser; nothing is uploaded. The rules live in one JSON spec, evaluated by a Python module and by a JavaScript file. A parity test checks that Python, JavaScript (when Node is installed) and the vectorised screen that produced the published results return the same flags on the same filings, including edge cases at each bound.

Mirrors
Functions plus data expectations: one rule definition evaluated in two runtimes and tested for agreement.
Repo paths
Live page
ehs-osha-analysis/filing_check.html
Limits
The rules are this project's plausibility screen, not an OSHA validation and not an official determination that a filing is wrong. The JavaScript parity test runs only where Node is installed.

4. Chemical-peers comparison page

A static page that puts any two size bands, product types, chemical families, inventory bands or release-history groups side by side. Release rate per plant-year gets exact binomial and Wilson 95% intervals and Fisher's exact test. Recordable cases per 200,000 hours gets an exact Poisson interval and an exact conditional binomial test. The page does no statistics: it looks up values precomputed into compare.json, and a test checks that file against the repository's committed outputs. The pull request that added it (#5) is merged.

Mirrors
Quiver-style analysis: pick two groups, see them side by side with intervals and a test. Also, in the same repository, a second ontology (join object PlantMatch between an EPA registration and an OSHA establishment, with match method, confidence and review status).
Repo paths
Live page
ehs-chemical-peers/compare.html
Limits
"Distinguishable from noise" means a p-value below 0.05 under a model where events arrive at one common rate. It does not cover plant-to-plant variation inside a group, so intervals are narrower than the real uncertainty when plants vary. It does not say why rates differ, and about 1 in 20 unrelated pairs will pass by chance. It is a comparison view, not Quiver.

5. Grounded claims registry

A JSON registry of headline claims. For each claim, a checker verifies that the claim text still appears on the named page, that the value in the named committed file in the source repository equals the expected value within a stated tolerance, and that the verifying test named in the registry still exists and still pins that value. It runs in a GitHub Actions workflow on pushes, pull requests and weekly, and exits 1 on any failure.

Mirrors
Data lineage and data expectations (health checks): every published headline number traced to a committed source file and guarded by a test.
Repo paths
Live page
None. The artifact is code and a markdown doc in the repository.
Limits
It proves that a page matches a committed file and a test, not that the file is right about the world. It covers the registered headline claims only, not every sentence on the sites.

6. Human-factors incident coding

Thirteen U.S. Chemical Safety Board investigations are listed with their csb.gov source URLs; those with codable text are coded to the performance-influencing-factor crosswalk, one row per investigation and factor with a quoted passage and a type (finding or recommendation). A generated readable view and tests check that every factor exists in the ontology, every source is a csb.gov URL, and every coding has a quote.

Mirrors
Ontology objects bound to evidence: each link from an investigation to a factor carries a quoted passage and an evidence type, and tests act as data expectations. The repository itself does not describe this as a Foundry design; the mapping is this page's reading.
Repo paths
Live page
None. The artifact is code and a markdown doc in the repository.
Limits
One coder and no second-rater agreement. Ten of the 13 investigations are coded, with 25 codings: a worked demonstration, not a sample of CSB work, and it says nothing about how common any factor is. Quotes are excerpts returned by a web-fetch tool and were not checked against the full PDFs, so verify a quote against its linked source before relying on it.

What this does not show