Who asks it what, and why one database instead of six.
Written for manufacturers. Every question below is answerable from public sources — once the organizations behind them have been resolved to each other and held over time. The examples are illustrative of question shape, not extracts of any client's data.
Eight desks, one record.
Each of these teams currently answers its own questions from its own sources, with its own idea of what an account is. They disagree, and nobody can reconcile them, because none of the underlying identifiers match.
Market accessCHANNEL AND TRADE
- Which covered entities added child sites in the last four quarters, and where?
- What is our contract pharmacy exposure, rolled to corporate parent rather than site?
- Which entities registered, terminated, or re-registered this quarter?
- Which nongovernmental hospitals depend on a government contract for eligibility, and who is the counterparty?
- Which entities are approaching the disproportionate share threshold from either direction?
WHY UNIFIEDExposure is a parent-level question answered from site-level sources. Without a resolved corporate hierarchy you are summing rows that may double-count one system and miss another entirely.
LegalLITIGATION AND DISCOVERY
- What was this entity's registered status on the date in question?
- What did it certify, on what date, and which cost reporting period did it name?
- Which entities held which arrangements during a proposed class period?
- Is this pattern isolated to one entity or systematic across the state?
WHY UNIFIEDA dated fact assembled in-house is a party document, created for the matter, with a methodology opposing counsel will characterise as self-serving. A third-party record built to a published methodology, before the question arose, for buyers with opposing interests, is a different object.
CompliancePROGRAM INTEGRITY
- Was this arrangement listed on the date of the transaction we are reviewing?
- Was the entity carved in or carved out of Medicaid on the dispense date?
- Which of our policy exemptions map to entities whose status has since changed?
- Where did a registry listing lapse and return, and over what interval?
WHY UNIFIEDEvery one of these is a question about a past date against a source that publishes only today and overwrites. Today's registry gives a confident wrong answer to all four.
Government affairsPOLICY AND STATE STRATEGY
- Which entities in this state would be affected by the proposed access mandate?
- How has participation in this state changed over the period under debate?
- What does the record show about growth, and what can we evidence in a comment letter?
WHY UNIFIEDPolicy arguments are attacked at the data layer first. A cited figure whose provenance runs to a worksheet line survives a hearing; one whose provenance runs to an internal spreadsheet does not.
Commercial analyticsFORECASTING AND TERRITORY
- What is the corporate rollup for this account, and when did it last change?
- Which sites of care sit under which parent, at what scale?
- Which accounts in the model refer to organizations that no longer exist under that name?
WHY UNIFIEDThis is the background-data case. Load persistent organization identifiers beneath the CRM, the forecast and the territory model and all three finally agree on what an account is — and every derived number traces back to a filing.
FinanceGROSS-TO-NET AND ACCRUAL
- What is our channel exposure by entity class and by parent?
- Which chargebacks reference entities or arrangements whose status we cannot verify for the transaction date?
- How has the eligible population moved over the accrual period?
WHY UNIFIEDAn accrual assumption is only as defensible as the population count behind it, and that count moves daily in a source nobody archives.
Medical affairsSITE AND INSTITUTION
- Which institutions treat this population, at what scale, under what ownership?
- Where does federal research funding concentrate, and at which affiliated parent?
- What is the actual legal entity behind this site, for engagement and transparency reporting?
WHY UNIFIEDTransparency reporting attaches to a legal entity. Engagement happens at a site. Those are different objects and the mismatch between them is a recurring reporting defect.
Corporate developmentSTRUCTURE AND CONSOLIDATION
- Which systems have consolidated, and when did the registry reflect it?
- Where is there real-estate or management-company exposure behind a nonprofit facade?
- Did an organization's reported behaviour change after a transaction closed?
WHY UNIFIEDThe transaction is in one filing system, the consequences in another, and the lag between them is only visible if both are held on one timeline.
What goes wrong without it.
Two failures from our own build. Both are the kind that produce a confident answer, which is what makes them worth showing.
Two sources agreed. Both were right. The answer was wrong.
A hospital pricing file was resolved to a different hospital, in a different town, and labelled corroborated — the highest confidence tier available. Two independent identifiers had voted for the same answer.
Both votes came from the file's system-level identifiers. Both were accurate assertions about a health system. Neither was an assertion about a facility, which is what the question had asked. Two system-level votes outnumbered one correct facility-level vote.
Scoring agreement across mismatched levels manufactures confidence rather than measuring it — and the manufactured answer carries the highest label. That is worse than an unresolved answer, because an unresolved answer announces itself.
The fix was to the specification, not the code. An implementation could follow the original spec exactly and still be wrong. In a measured comparison on a 29-hospital cohort, name-and-address matching disagreed with the identifier route in 13% of cases where both fired, with the identifier route correct every time. That cohort is non-random and unusually compliant; treat the figure as illustrative of the mechanism, not as a population estimate.
A listing present on the 2nd, absent on the 3rd, and gone forever by the 5th.
A contract pharmacy arrangement appears in the registry one day and not the next. The registry publishes only current state, so by the time anyone reviews a transaction from that week, the arrangement simply does not exist and never visibly did.
With the record held, the statement becomes precise: on the 5th this pharmacy was not listed for this entity, and the listing ceased sometime between the 2nd and the 3rd. Not a date — an interval, because the source overwrites and we observe states rather than events.
That interval is the factual predicate. It is not a conclusion about any transaction, and we do not offer one. It is the fact neither party can currently establish, and both need.
This is also the case for daily rather than weekly capture. Daily bounds the change to a day. Weekly bounds it to a week — and loses entirely any listing that appeared and disappeared inside it.
Connecting it to your own models.
You already have an assistant, a copilot, or an internal agent. The reason it produces confidently wrong answers about healthcare organizations is not the model. It is that licensed data ships numbers without semantics. Every value in our feed carries a Sourceprint™ instead — the unit, grain, source line, period, observation date, null semantics and do-not-conclude statement, travelling with the number.
A field arrives as a column header and a value. Nothing tells the model that the number is a cost rather than a charge, that it is reported per fiscal year rather than per quarter, that a blank means the filer never filed rather than that the figure was zero, or that the adjacent column overlaps with it and the two must never be summed. The model fills those gaps the way models do — plausibly.
Every field in the feed carries that missing layer as its Sourceprint™. Unit, grain, source form and line, the period it describes, the capture it came from, what a blank means, and an explicit statement of what not to conclude from it. That is the part that turns retrieval into something a reviewer will sign.
It is a method, not a document dumpINTEGRATION
Your model calls the feed the way it calls any other tool — resolve an organization, fetch a field, pull a time series, list what changed. Constrained parameters rather than free-text query, so the model cannot ask for something the data cannot support.
Answers arrive pre-citedREVIEW
The citation comes back with the value, in a form your reviewers already accept — form, worksheet, line, period, observation date. An unsourced number cannot leave a regulated company. A pre-sourced one goes straight into the deck.
Never a silent matchRESOLUTION
The resolver returns candidates with confidence, not a single guess. Unresolved is a valid answer the model is expected to report rather than paper over.
Reproducible after the factAUDIT
Every answer names the capture behind it, so any past answer can be re-run and re-derived. Your team owns that audit trail; we never see the questions.
Your prompts do not rotSTABILITY
Field names never change meaning — they are only added to, and a rename ships as an alias with an overlap window. Work you build on the vocabulary keeps working.
We can supply an evaluation set: questions with known-correct answers and citations, including the ones designed to fail — overlapping fields, mismatched grain, blanks that are not zeros, and questions whose correct answer is that the data cannot support one. Run it against your current stack and against ours, in your environment, and compare. Nothing leaves your network.
Questions we get asked.
THE DATA
Is any of this proprietary or licensed from a third party?
If it is all public, why can't we assemble it ourselves?
What can't it answer?
How far back does the record go?
SECURITY AND POSTURE
What data of ours do you hold?
Do you sell to organizations on the other side of our disputes?
Would we be exposed by the way you collect this?
COMMERCIAL
How is it priced?
Can we evaluate it before committing?
What happens to what we built if we stop subscribing?
Can we redistribute or embed the outputs?
METHOD
How do you decide two records are the same organization?
What happens when sources contradict each other?
What if you get something wrong?
Is a model doing the matching?
A question we have not listed here is usually still a dated one.
Send it and we will tell you whether the record supports it, what it would take, or that it is outside the boundary.