Project kickoff where every fact retains its source

Later in a project, tracing a date back to its source can take an afternoon. The answer may be in a forwarded email, an attachment, or a call note, while the retyped plan no longer retains that connection. Retyping removes source information and can turn unresolved contradictions into accepted facts.

Originals stay originals

In the start room we built, the packet contains generated email files in the RFC 822 standard and PDF files, with no client correspondence. The parser retains message structure and identifiers, the PDF inspector selects the appropriate text-extraction method, and a SHA-256 checksum verifies each file's bytes.

The material yields facts such as commitments, dates, and scope items, each with a locator pointing to its exact place of origin. Actions in the plan point to the facts that support them. The resulting chain runs from source file to fact to action and can be followed in either direction. A question raised in week three can return to its original source in three clicks.

Forwarded copies count as one source

Starting packets create a specific illusion: the same email forwarded three times looks like three independent sources. A normalized content hash ties forwarded copies to their original, so each forward adds no new confirmation. Three copies of one declaration still count as one source.

The conflict blocks; a human resolves

When an attachment gives a different date from the commitment recorded in a call note, the system creates an open conflict instead of selecting either value. The conflict blocks plan import until a person resolves it.

In production, an authenticated role resolves the conflict, records the reason, and separately locks the plan version. The controlled demonstrator cannot verify identity or role, so both write controls remain read-only. The integrity chain detects a changed stored event but does not provide write-once storage. A local model runs only in a separate format check outside the public API.

The minimum provenance chain

A practical model contains five objects: source file, location in the file, commitment, plan action, and decision. Every object has a stable identifier. A user can move from a task to the sentence that justifies it and from a source to every action derived from it.

Locators should be readable: message identifier and paragraph, page and sentence, or recording timestamp. An embedding or semantic-similarity score alone is not a sufficient source reference.

Implementing a start room

1. Agree a closed list of accepted input formats.
2. Preserve original files, message identifiers, and checksums.
3. Define commitment types: date, scope, owner, dependency, condition, and risk.
4. Link every action to at least one commitment and locator.
5. Detect copies through normalized content while retaining each original.
6. Store contradictions as open issues with an owner.
7. Separate conflict resolution from plan-version approval.
8. Export to the project tool only after required gates pass.

Run the first pilot alongside the current kickoff method. Compare plan completeness, open questions, preparation time, and later requests to reconstruct a source.

Conflicts need different rules

A conflicting start date may hold the plan. A missing action owner may enter a queue without blocking, depending on the process. Gaps have different severity. Before implementation, decide which conflicts stop approval, which produce warnings, and which may remain open.

A decision should record the person, selected value, basis, and reason. Selection can be limited to values present in evidence, or a new value can be explicitly marked as a human-entered commitment.

Common failure modes

An email parser may lose thread structure, a PDF may lack reliable text, and a forwarded message may differ through footers or formatting. Deduplication needs control cases to avoid merging similar but independent commitments.

Application-only integrity is another risk. If the database accepts an action with no commitment reference, an import or manual operation can bypass the interface. Critical links should be enforced in the data schema. A hash chain reveals history changes, while stronger audit requirements may need external anchoring or durable storage.

The measurement

All 14 checks passed on the generated packet: four files, three unique contents, eight commitments, five actions, and one conflict. The checks cover action-to-commitment references, the initial held state, both read-only controls, and audit continuity. The one-page PDF required no OCR. Three local format checks completed at a median of 509 ms with PLN 0 in external API fees.

The process requires some structured work at kickoff. In return, the team gets a plan whose facts remain connected to their sources and whose known contradictions stay visible.

The local model check incurs no external API fee, but implementation cost sits mainly in format integrations, conflict rules, identity controls, and the project-tool connection. A pilot should track plan-preparation time, actions with a source, detected duplicates, open conflicts, and provenance questions raised after kickoff.

Project-lead checklist

• Does every date, scope item, and condition lead to an exact source location?
• Do forwarded copies retain separate files but one content confirmation?
• Do hold rules distinguish critical conflict from an ordinary gap?
• Does each resolution record owner, basis, and reason?
• Is plan approval a separate event?
• Does the data schema require every action to reference a commitment?
• Can export to the project tool be held and retried?
• Can the team reconstruct the plan version used at a given time?

Details on the case page, and a free process scan will help assess how much your projects lose at the start without fact provenance.