Fact provenance at project kickoff

At project kickoff, a date may arrive in an email, a file attachment, a meeting note, or a message forwarded by somebody else. If a person retypes it into a plan without retaining the source, the team loses the ability to check what the date meant and who supplied it.

Decide whether the project needs a source-linked decision record. It is worth the work when several people contribute evidence, the plan will drive actions, or a later dispute would be expensive to reconstruct.

The kickoff record has four layers

Keep four separate objects in the record:

1. Source artifact: the original message, attachment, document, recording reference, or structured record.
2. Extracted fact: a date, owner, dependency, scope statement, condition, or other claim, with a locator in the source.
3. Decision: the person, role, or rule that accepts, rejects, or leaves the fact open.
4. Action: the task, update, or communication that follows from the decision.

The W3C PROV-DM model describes provenance through entities, activities, agents, derivations, and responsibility. A kickoff record does not need to implement every part of that model, but the vocabulary is useful: preserve the source, identify the activity that extracted the fact, and retain responsibility for the decision.

Preserve the source artifact

Store the original file or a stable reference before extracting text. Keep its media type, source system, message or record identifier, received time, effective date when available, and access policy. A locator should be useful to a reviewer: page and paragraph for a document, message ID and section for an email, timestamp for a recording, or row and column for a table.

A normalized content fingerprint can group forwarded or duplicated files. That prevents three copies of one email from being counted as three independent confirmations. Keep the original identifiers as well, because a normalized value is a comparison aid and not a replacement for the source record.

For file integrity, NIST FIPS 180-4 specifies SHA-256 and related secure hash algorithms. A matching hash says that the compared bytes match. It does not say that the content is true, current, or approved. Store the hash with the source metadata and keep authority and effective-date fields separate.

Link facts to actions

An action should not contain only a sentence generated from a source. It should point to the fact that supports it, and that fact should point to a locator in the source. This creates a chain that works in both directions:

• from a task to the commitment, date, or condition behind it;
• from a source passage to every task that relies on it; and
• from a decision to the evidence and version visible at approval time.

Keep extraction and interpretation separate. A document can state that a delivery is planned for a date without establishing that the date is feasible. The first becomes an extracted fact. The second requires a decision, an owner, or another source.

Treat conflict as an open state

If an attachment and a meeting note contain different dates, retain both statements and mark the dependent item as conflicted. Do not choose the value that was parsed first and do not ask a language model to blend the two into one sentence.

The conflict record needs the competing source locators, the affected plan items, an accountable resolver, and a status. Once resolved, store the chosen value, the reason, the person who decided, and the source version used. If the resolution changes an action already released, create a new plan version rather than rewriting history.

Put controls in the data model

Useful fields are more important than a polished interface. At minimum, define:

• stable IDs for artifacts, facts, decisions, actions, and plan versions;
• source locator and source access rule;
• created, received, effective, and superseded timestamps where relevant;
• confidence or extraction status, kept distinct from approval status;
• conflict status and resolver;
• relationship from each action to its supporting facts; and
• audit events for edits, approvals, and releases.

The W3C PROV-O ontology can help map these relationships to a standard vocabulary when records must cross systems. A simpler relational model is fine when it preserves the same trace.

A practical kickoff workflow

1. Agree which source systems and file types the project accepts.
2. Capture originals and metadata before parsing or summarizing.
3. Extract candidate facts with locators and an extraction status.
4. Group likely duplicates without deleting their original identifiers.
5. Link each proposed action to its supporting facts.
6. Create an explicit conflict item for competing current sources.
7. Route unresolved conflicts to a named person.
8. Release a version of the plan only after its blocking items are resolved.

Keep a human decision in the chain wherever the system cannot determine authority. Automation can locate passages and propose links. It should not silently turn an ambiguous statement into an approved commitment.

Decide what blocks approval

Not every uncertainty should stop a plan. Agree the blocking rules with the project owner. A missing owner for a high-impact task, a conflicting deadline, an inaccessible source, or a failed parser may require a pause. A minor wording difference in an internal note may only need a review flag.

The rule should be visible to the person approving the plan. Record the reason for a block and the condition that clears it. This makes the system predictable and gives a team a way to improve its source and decision practices.

Measure traceability

Choose measures that describe the record rather than the model's confidence. Examples include the share of facts with a usable locator, the share of actions linked to at least one accepted fact, the number of unresolved conflicts at release, and the time needed to answer a source question. Review a sample for locator accuracy and authority, because a link can exist while pointing to the wrong passage.

Measure again after changing parsers, source connectors, deduplication rules, or approval logic. Provenance is useful only while the chain remains current.

When provenance is worth the work

Use a lighter record for a small project with one owner and a stable source. Add a richer provenance layer when the kickoff packet combines email, files, notes, and system records; when different teams have different access; when actions are created automatically; or when the plan may be challenged later.

If the business cannot name an owner for a source or a decision, fix that ownership first. A provenance interface cannot create authority that the process does not have.

FAQ

Is a source link enough? No. The link needs a stable locator, access rule, source version, and a relationship to the fact or action that used it.

Should the system delete duplicate forwarded messages? Keep the originals and group likely duplicates. Deleting them removes context and makes later investigation harder.

Can an AI model decide which conflicting date is correct? It can surface the conflict and explain the competing passages. Authority and acceptance should remain with the accountable project role.

Sources

• W3C PROV-DM: The PROV Data Model
• W3C PROV-O: The PROV Ontology
• NIST FIPS 180-4: Secure Hash Standard