Agent-Ready Data Audit
I'm Madeleine Muscari. I spent seven years as Principal Engineer on Twilio's API gateway and hold two patents on how it worked. Now I read databases for people who are about to let something automated query them. You get a written report with the queries I ran and what came back.
Yours probably works fine. It has fed a BI dashboard for years, watched by people who know which columns lie and which joins to avoid. That knowledge lives in their heads. It was never written down anywhere the database can see.
Then you add an operational dashboard, or connect an agent over MCP, or start forecasting on last year's numbers. The new readers don't have any of that context. A location spelled three ways is three locations to them. A join that quietly drops a third of the rows still returns a number, and the number looks reasonable.
What goes wrong
In your report each one comes with the column it's in, the query I ran, and the number that came back.
Section 1Type discipline
Dates, quantities and flags kept as text. The view layer converts them on every read, so anything reading the tables directly gets a string back instead. When three date formats share a column, nothing in the schema says which one you're holding.
Section 2Referential integrity
Location and role mappings written into CASE WHEN blocks inside view definitions instead of kept in tables. Leave one out and the join doesn't fail. It returns NULL, and those rows drop out of the result. Adding a location means editing every view that has a mapping in it, and there is usually no list of which ones do.
Section 3Ingest provenance
Nested REPLACE chains cleaning up encoding damage and spelling variants on every read. Usually the damage happened once, at ingest, and has been patched downstream ever since. You can fix the chain in an afternoon. Fixing the ingest is the part that stops it coming back.
Section 8Access and exposure
Reporting schemas collect personal data because some report needed it once. Home addresses, birth dates, pay rates. Grants are per table, not per column, so anything with read access to the table has read access to all of it.
What the audit is
Observation, evidence, impact, risk, recommendation. The evidence is the actual query and the actual result, not a description of them.
The report covers eight areas: type and format discipline, referential integrity, ingest provenance, indexing and query planning, storage lifecycle, time semantics, operational posture, and access and exposure. There's an appendix on the ingest pipeline, which is where most of the causes turn out to be.
After the audit
Most people take the report and stop, and that's a finished piece of work. But the audit exists because I build the thing that comes after it, and I have taken a client through all three phases.
The same person does all of it. Whoever read your schema is who rebuilds it, which is why Phase 1 doesn't open with another month of discovery.
The audit
One week, fixed price, read-only. You get the findings, the evidence behind each one, and a ranked list of what to fix. Yours whether or not we work together again.
The rebuild
The schema the audit says you should have had. Reference tables instead of mappings buried in view definitions, real types instead of text, foreign keys that actually hold, and an ingest path that fixes data where it enters rather than patching it on every read. Built alongside what you have now, so nothing stops while it happens.
The agentic ERP platform
An MCP server your agents can query without guessing, an operational dashboard reading the same schema your finance numbers come from, and forecasting built on your own history. This is the part that only works if the first two happened. Pointing agents at an unrebuilt warehouse is how you get confident wrong answers at speed.
Terms
Price
Fixed. If you go on to a rebuild, it comes off that.
Timeline
From when the access actually works, not from when we agree to it.
You provide
Read access to a replica, and answers to four questions. I collect the evidence myself. Nothing I run writes.
Scope boundary
I read structure and statistics: the schema, the profiler output, the pipeline. I don't reconcile values against production data. That's a bigger job and it belongs in a later phase. Drawing the line here is what keeps the price fixed and keeps me off your live database.
Who runs it
Twenty years in platform engineering. Seven of them at Twilio, where I was Principal Engineer on the REST API gateway at 99.999% uptime and designed the next version of it. I also built the write-path queueing system and the data-processing behind GDPR and HIPAA compliance there.
After that: Staff Software Engineer at Weights & Biases, running the public GraphQL API and the storage under it. Senior Staff at Material Security, leading the Platform team, where I started a finops practice that took 30% off cloud spend in three months. Most of that work was just measuring things nobody had measured. Then founding engineer at DeepKeel, building a framework for inspecting and auditing code written by LLMs.
Before all of it, graduate research at Rutgers on distributed systems, and a single-author paper on finding roles in social graphs using constrained non-negative matrix factorization. That was about recovering structure from a graph nobody had labelled, which is roughly what reading an undocumented warehouse turns out to be.
I run the tooling myself and I wrote the report format. You are not getting a template scan or a junior with a profiler.
US11601519B2 Edge Communication Locations · US20220405119A1 API Request Throttling.MySQL PostgreSQL Cassandra MongoDB · AWS, GCP, Azure · Python, Scala, Java, Go.Next step
Database engine and version. Whether you can give me read access to a replica. Who signs off on technical decisions. What you're building next. You don't need to book a call to find out.
If you don't have a database yet, or you're pre-product, this isn't for you. If you have a warehouse that's worked for years and you're about to ask more of it, it probably is.