How we work
When reports disagree or work stalls between teams, the first explanation is rarely the only one worth testing. We investigate across people, software and operational records. AI helps find connections; senior specialists check the interpretation and what to change.
Start with the disagreement
A report can be internally consistent and still answer the wrong business question. Before recommending a new dashboard, a system replacement or a change of owner, we establish what the disagreement actually is.
The workflow below explains how we investigate this kind of question. It is not a reconstruction of a client's private research record or a claim about which tools were used in a past engagement.
How we test the explanations
01 / Competing explanations
Are the reports measuring different things? Applying different cost rules? Comparing different periods? Or does the implemented calculation differ from the intended definition? Each explanation needs a check that could support or challenge it.
02 / Independent verification
Define the business measure, included records, relevant statuses and time window. Then compare authorized source-system records using read-only queries or reproducible extracts. Check identifiers, filters and aggregation rules before interpreting the difference.
03 / Mechanism and context
Code and dependency mapping helps locate the calculation; recorded discussions and decisions can explain changing context. Investigators return to underlying code and original records. A graph connection or generated summary is a lead, not proof. Independent data checks must be allowed to disagree with both.
04 / Senior interpretation
Technology, analytics and organizational specialists ask whether the evidence supports a calculation problem, a definition dispute, an ownership gap or an unresolved question. Missing records and credible alternatives stay visible. Runtime claims need tests, configuration or traces, not source code alone.
05 / The next decision
Depending on the evidence, the priority may be to agree a definition, correct a calculation, assign a control owner or gather more evidence before changing a system. Findings state their support and limits; proposed actions identify dependencies, responsible roles and completion evidence. Leadership decides what to adopt.
What the public case establishes
In a publishing and e-commerce engagement, Blatt investigated conflicting reports across reporting logic, product records, conversations and departmental responsibilities.
The investigation documented inconsistent cost treatment and mismatched reporting periods. It also identified missing checks between product promises and product content. These were distinct issues to examine, not evidence that one mechanism caused every discrepancy.
The handover included an evidence register, prioritized actions and engineering handoffs. Financial impact remained subject to corrected calculations and policy decisions, rather than being treated as savings already achieved.
These are the bounded observations already described publicly, not a record of every verification step or tool used. The case does not establish quantified savings, CTO-onboarding or VC-referral outcomes, or participation by every expert in the current roster.
Review how we test this kind of disagreementThree instruments
MemoryOS / History
Our proprietary research infrastructure supports navigation through organizational history and back to source conversations. What someone said is evidence of their account, not proof of formal ownership or causality.
Atlas / Code
Code and dependency mapping guides source inspection across relevant systems. A map does not establish deployed behavior: runtime claims need configuration checks, tests or traces.
Independent data verification
Read-only SQL, APIs and reproducible comparisons test the account against primary records. Align identifiers, statuses, time windows and aggregation rules before interpreting a difference.
Tool selection, technical readiness, source availability and permissions are scoped for each engagement. These are investigative instruments, not a universal connector product or a ready-on-day-one runtime promise.
Senior judgment
Technology, analytics and organization specialists challenge competing explanations and second-order risks together.
The recommendation may be to change, defer or retain. A technically attractive fix can create a new operational problem; an apparent ownership gap may require a leadership decision rather than more code. Your company retains the decision.
Meet the experts and their rolesThe handover
What the approved records directly support, with source references.
The explanation we consider plausible, and why alternatives remain weaker or open.
Missing records, conflicting accounts and the next check needed.
What to change, defer or retain, with prerequisites and owner roles.
A scoped map, evidence-linked findings, prioritized 30/60/90-day plan and first implementation brief form the working handover. The standard investigation takes four weeks after agreed access is available. Broader implementation is scoped separately.
Review service scope, outputs and access requirementsAccess by agreement
We agree sources, exclusions, permissions, recipients and data arrangements before starting. Engagement work uses client-controlled GCP and client-supplied model API access. Approved model requests may leave GCP for the selected external provider; client control does not mean all processing stays inside that environment.
Read the data-handling boundariesStart with the question
Bring the decision, the disagreement and the sources you may be able to authorize. No confidential records or credentials are needed for the first conversation.
Discuss your situation