The project plan says the equipment will arrive on the 12th. The supplier's email says the 19th. The customer presentation, assembled yesterday, still says the 12th.
All three are searchable. All three can be summarised. Connecting them to an AI system does not decide which date the team should use.
For project and operational leaders, this is where connected information must become connected judgement. The useful question is what each source establishes, which work depends on it and who needs to resolve the difference.
Conflicting project information occurs when records make incompatible claims about the same relevant condition. Resolving it requires checking their meaning, scope, version and authority, then recording the decision and its consequences. Recency alone is insufficient.
Connection is becoming the starting point
Asana's 30 September release places shared context, AI teammates and actions across existing tools at the centre of its proposition. That is a vendor announcement, not an independent comparison, but it illustrates how familiar the language of connected work has become.
The question for a buyer is increasingly what happens once the information is connected. Does the system preserve a disagreement? Can the team examine the affected work? Does the final record explain why one interpretation governed the response?
A source link helps the user find a document. It does not, by itself, establish that the document supports the conclusion drawn from it.
First establish whether the sources really disagree
Take an illustrative launch of a new fulfilment service. The plan schedules equipment delivery for the 12th. A supplier update gives the 19th. Training, acceptance checks and the first customer commitments depend on having the equipment ready.
Before moving the whole schedule, the team needs to know what the two dates mean. One might refer to dispatch and the other to arrival. One may concern only part of the order. The later email might be a forecast that has not yet become a confirmed commitment.
If the dates concern different events, the problem is a missing distinction. If they concern the same delivery, the team has a conflict to resolve. Those situations require different responses.
Useful project intelligence should help expose that difference. It should retain the source location and relevant wording, make the scope visible and avoid filling the gap with an attractive guess.
The newest record does not automatically govern
There are several ways to arrive at a neat but unreliable answer.
One is to choose the latest timestamp. That can promote a draft over an approved record. Another is to count how often a date appears. Five documents may all repeat one outdated assumption. Repetition is not independent evidence.
Nor should the system blend incompatible accounts into a convenient middle position. A compromise date invented by a summary is not a supplier commitment.
The team needs an agreed basis for deciding which records govern which matters. Commercial terms, operational forecasts and formal acceptance can have different owners and different meanings. The relevant authority comes from the organisation's process and agreements.
Keeping versions distinct is already a visible product concern. Glean's 1 October release includes a check intended to prevent an older agent edit from overwriting a newer published version. That feature concerns agent configuration, not project evidence, but the underlying lesson travels: a newer state should not disappear because a system failed to recognise a conflict.
Follow the uncertainty into the work
Suppose the supplier confirms that the 19th is the revised arrival date. The original delivery assumption is now superseded. The customer launch date is not automatically superseded with it.
The team must examine the dependency path. Can training use another unit? Do acceptance checks require the full order? Is there time between arrival and the first customer commitment? Does a different sequence preserve the outcome without weakening the acceptance criteria?
These are project questions. A system can help organise the evidence and identify possible consequences, while the people responsible judge the feasible response.
Where the delivery date remains unresolved, the uncertainty should stay attached to the work it affects. “Supplier date awaiting confirmation” is more useful beside the dependent acceptance check than buried in a general risk summary.
The rest of the project should remain legible. One uncertain dependency need not make every unrelated activity look equally uncertain.
Preserve the route from evidence to outcome
A useful decision trail lets another authorised person follow five relationships.
The change: the specific claim or condition that differs, with its source and version.
The impact: the work, assumptions or commitments that may be affected, with the dependency path and unresolved gaps.
The response: the proposed option, its supporting evidence and the alternatives considered where material.
The authority: the person who accepted the response, its scope and any conditions.
The outcome: what was actually updated or carried out, with evidence of completion or a visible pending state.
These relationships can live across existing records. The value is being able to follow them without reconstructing the whole episode from memory.
They also distinguish an authorised response from a completed one. A revised plan can be approved while a supplier acknowledgement remains outstanding. Recording that difference helps the next person know what still needs attention.
A useful evaluation starts with imperfect evidence
When evaluating project AI, include a case with two conflicting records. Use material the team is authorised to share, and agree the expected interpretation with a project professional beforehand.
Observe whether the system identifies the conflict and keeps the sources distinct. Check whether its suggested impacts follow the actual dependencies. Ask it to show which conclusion is supported and which still needs confirmation.
Then resolve the conflict. A second reviewer should be able to see why the chosen source governed the decision, what changed and what remains unfinished. Their understanding is a more useful result than a demonstration that merely ends with a clean summary.
This is a proposed evaluation approach. It does not assume that every conflict can be detected, that every dependency is recorded or that a model can determine contractual authority unaided.
Where Panovia fits
Panovia is connected project intelligence for work that changes. We are building around the relationship between project evidence, dependencies, possible consequences and the decisions that shape delivery.
The organising principle is simple: the reasoning should remain attached as the project changes. In an evaluation, that means examining a real chain from a source update to affected work, a named decision and its recorded outcome. The supported sources, actions and limits should be clear for the workflow being tested.
Nothing changes alone. When the sources disagree, the team's first advantage is being able to see the disagreement clearly enough to resolve it.
Questions readers may be asking
How should AI handle conflicting project sources?
It should preserve the competing claims, identify their scope and provenance, show relevant consequences and surface the need for a decision. Choosing a source should follow the organisation's authority rules and available evidence.
Is the latest document always the correct one?
No. A later document may be a draft, refer to a different scope or repeat an error. Version, effective date, approval status and the authority of the source all matter.
What is the difference between an activity log and a decision trail?
An activity log records events. A decision trail connects relevant events to the evidence, interpretation, authority and outcome that explain a change. Both can be useful, and neither guarantees that the underlying judgement was correct.