Data systems investigations

Understand why your data changed.

Pulaski Data Corporation builds tools for data teams whose systems have become too complex to understand from any single database, repository, dashboard, or person.

Read about readonly Discuss a design partnership

Problem

The data is there. The explanation is scattered.

Modern data organizations already have the context needed to explain what happened. It is spread across the warehouse, transformation code, orchestration, query history, pull requests, tickets, dashboards, documents, and the memories of senior engineers.

Answering a straightforward question means manually joining those sources together. The work is slow, difficult to repeat, and usually depends on the same few people.

The question	What a reliable answer requires
Why did this metric change?	Data diffs, lineage, job runs, code changes, and the decision behind the change.
Where are our quality checks blind?	Profiles, test assumptions, historical behavior, and domain expectations.
Can we trust this answer?	The authoritative definition, query, source tables, dashboard logic, and known caveats.
What can we safely remove?	Usage, cost, dependencies, ownership, and operational intent.

Approach

Use primary sources, not another model of them.

A good senior engineer does not know every detail. They know where to look, which sources to trust, and how to test an explanation.

We do not believe data teams should maintain a second semantic representation of an organization just so AI can use it. That representation starts decaying as soon as the real system changes. The real context already exists in the systems where people do their work.

The useful context layer is simpler: a map of where to look, how the organization operates, what is authoritative, and how to investigate safely. The agent should be allowed to inspect the source, form a hypothesis, test it, and show its evidence.

Solution

Product under development

`readonly`

Design partner phase

Ask your data system why.

readonly is an investigation agent for data teams. Give it permission to read the warehouse, code, pipelines, operational history, and team records. It follows the evidence and returns an explanation that people can verify.

1	Inspect the actual system and locate the change.
2	Trace lineage, execution, code, and decisions.
3	Test competing explanations against the data.
4	Report what happened with source-level evidence.
5	Remember where to look the next time.

Example

Question	Why did weekly active households fall 7.4%?
Evidence	`analytics.household_activity`, `pipelines/households/daily.sql`, commit `8e73c1f`, and ticket `DATA-1842`.
Finding	A production filter explains approximately 91% of the decline. The change was intentional; no upstream volume anomaly was found.

Designed around read access, explicit permissions, and evidence attached to every conclusion. It is not an autonomous operator making unreviewed production changes.

Partners

We are looking for five design partners.

We want to work with 10–50 person data organizations running a mature stack inside a complex business. Bring us one real incident that required a senior engineer to untangle. We will investigate it with you and learn what the product must become.

Discuss an investigation hello@pulaskidata.com