The Audit Trail Is Half the Agent

Every AI demo in this industry looks the same. An analyst types "what delayed substantial completion?" and an agent produces a confident, well-organized answer in thirty seconds. The room is impressed. Nobody asks the question that will actually be asked, months later, in a deposition: how do you know?

Forensic schedule analysis produces evidence. Evidence gets challenged. An answer that cannot show its work is an opinion, and an opinion generated by a language model is an opinion that opposing counsel will take apart with pleasure. The difference between an AI toy and an AI instrument comes down to a property the demos never showcase: whether the investigation can be replayed.

Two Ways to Build an AI Analyst

There are two architectures for putting a language model in front of schedule data, and they produce evidence of very different quality.

The first hands the model the data and asks for conclusions. Load the activity tables into context, ask what drove the delay, let the model reason it out. This is the architecture you get by default when someone pastes schedule exports into a chat window. The model becomes the measuring instrument. And language models are probabilistic instruments: ask twice, get two answers. Excellent at reading, summarizing, and noticing. Unreliable at arithmetic across ten thousand activities, and structurally incapable of showing how a number was derived, because the derivation happened inside a forward pass no one can inspect.

The second architecture keeps the model away from measurement entirely. The model navigates: it decides which questions to ask, in what order, and what the results mean for the next step. Every measurement comes from a deterministic engine invoked through a typed tool call. The model asks "what is the driving path to this milestone?" and a CPM engine computes it. The model asks "which changes in this window pushed the milestone?" and an attribution engine measures it. The model's prose is a narration of tool results, and every number in that prose has a computation behind it.

We wrote about this division of labor in Calculator vs Mathematician: the tool computes, the agent navigates, the analyst decides. What that post left implicit is the evidentiary consequence. The navigator architecture doesn't just produce better answers. It produces answers with provenance.

Three Properties, All Load-Bearing

Provenance is only worth something if three properties hold together. Lose any one and the audit trail becomes decoration.

• Deterministic tools. Same inputs, same outputs, every time, on every machine. That property has to be designed in and then defended: FPM's engines are regression-tested with hard equality against thousands of golden-file impact values from real project data, checked on every build. If any code change moves any of those numbers, the build fails.
• Versioned engines. Algorithms improve. When they do, old results must stay explainable. Every FPM analysis records the exact engine versions that produced it, and the changelog states what each version changed. "The number moved because we corrected calendar handling in version 0.3.2" is an answer. "The number moved" is a problem.
• Logged tool calls. Every invocation the agent makes is recorded: which tool, what parameters, what came back. The log is the investigation. Read it top to bottom and you can watch the agent scan the windows, find the anomaly, drill into the driving path, and pull the numbers that ended up in the report.

Notice the dependency chain. Logged calls are only replayable if the tools are deterministic. Determinism across time only holds if engine versions are pinned and recorded. The three properties are one property: the investigation can be run again, by anyone, with the same result.

The Cross-Examination Test

Picture the deposition. Your report says the duct rerouting in Update 14 pushed Substantial Completion by 47 days. Opposing counsel asks how that figure was determined, and whether the AI you used could have made it up.

With the navigator architecture, the answer is boring, which is exactly what you want from evidence. The figure came from a delay-analysis computation, at a recorded timestamp, with recorded parameters, executed by engine version such-and-such. Here is the tool call in the log. Here are the schedule files it ran against. Your expert can install the same tools, run the same call, and confirm the same 47 days. The language model wrote sentences around that number. It had no ability to alter it.

With the instrument architecture, the honest answer is that the model read the schedules and concluded 47 days, and that rerunning it might conclude something else. Cross-examination of that answer writes itself. It only takes one "the AI estimated it" moment to taint every other number in the report, including the ones that were right.

The standard here isn't new, and that's the point. Expert work has always been held to reproducibility: another expert, given the same data and method, should reach the same result. Agents don't get an exemption because they're impressive. The architecture either meets the standard or it doesn't.

What the Model Is Actually For

None of this diminishes the model. Navigation is the hard, valuable, previously-human part: choosing what to look at across 40 schedule updates, noticing that the critical path shifted in Window 8 and never shifted back, connecting a logic change to a correspondence date, drafting the finding in language a tribunal can follow. The model does in minutes what used to take a week of clicking through P6 filters.

It also doesn't diminish the analyst. Someone decides which questions matter for this dispute, which methodology the contract calls for, and what the measured numbers mean under it. As we argued in Directing the Agent, the analyst's playbook is what turns agent speed into analytical value. The audit trail is what turns analytical value into evidence. You need both, and neither one is the model.

This is why FPM exposes its forensic capabilities as structured tools over the Model Context Protocol rather than piping schedule data into a chat context. Typed parameters in, deterministic results out, every call logged. Any agent, ours or yours, that works through those tools inherits the audit trail for free.

So the next time you watch an agent demo answer a forensic question in thirty seconds, be impressed, then ask the boring question: can I see the log? If the vendor lights up, you're looking at an instrument. If they change the subject, you're looking at a very fluent liability.