Emails, attachments, and meeting notes become one plan with visible sources and unresolved differences.
The system gathers commitments from kickoff material and assigns each one a source, owner, and date. It recognizes forwarded copies so they do not count as extra confirmation. A conflicting date stays open for the project lead to decide.
What we measured
The reference implementation keeps the source of each commitment, detects the forwarded copy, and leaves conflicting dates open for a decision. It is read-only, uses one synthetic packet, and contains no client data.
- Local test
- What we measured
- Source, conflict, and write-block checks
- A sourced project kickoff plan
- Verified
- synthetic material
Problem, solution, and result
The problem
A project start is spread across several emails, an attachment, and meeting notes. The project lead retypes the commitments into a plan, losing their origin and potentially counting a forwarded copy as separate confirmation.
How it works
The system reads the files, identifies duplicates, and links actions to specific source passages. Conflicting dates and missing owners remain on an open-issues list. A person resolves them before the plan version can close.
Fourteen checks on a single packet
The reference implementation keeps the source of each commitment, detects the forwarded copy, and leaves conflicting dates open for a decision. It is read-only, uses one synthetic packet, and contains no client data.
For whom
This system fits teams that build kickoff plans by retyping emails, find different dates across the source files, and later cannot trace a commitment back to its origin.
Packet → commitments → dispute → plan
- 01Every commitment shows the file and the place it came from
- 02A forwarded copy never counts as a second confirmation
- 03A person seals the plan version once the date is resolved
- Business type
- Integrators, software houses, and project-delivery businesses
- Input
- The kickoff packet: an .eml thread with its forwarded copy, a PDF attachment and a kickoff note
- Boundary
- An open dispute over the go-live date keeps the plan version open; a person decides and puts their name on the date
- Cost
- PLN 0 in external API fees for the recorded run; 3 answers prepared locally, 509 ms median.
- Security
- A conflicting date remains open, and saving the plan requires a decision and signature from the responsible person.
- Trace
- Every commitment links to a specific file or passage, and the history exposes later changes to a record.
- Similar system build
- from €6,000 net (approx. $6,500) · 4–10 weeks
The plan's boundary
The project lead resolves the disputed date
The system does not choose between conflicting dates or merge contradictory commitments. In production an authenticated person selects the binding date, gives the reason, and signs the decision. Sealing the plan is a separate step. The demonstrator cannot verify identity or role, so both actions remain read-only and both write attempts are refused. An action without an owner stays on the open-points list, while the unresolved go-live date keeps the plan itself open.
- Boundary
- An open dispute over the go-live date keeps the plan version open; a person decides and puts their name on the date
- Cost
- PLN 0 in external API fees for the recorded run; 3 answers prepared locally, 509 ms median.
- Security
- A conflicting date remains open, and saving the plan requires a decision and signature from the responsible person.
What the reference implementation does not yet enforce
The demonstration checks source links in the application, while the database does not enforce every relationship. It also has no account-import function. Production needs stronger source enforcement, implemented import approvals, and an audit record protected outside the application database.
Estimated impact
Calculate the impact at your volume
This estimate uses the stated volume. Enter your own numbers to assess the possible impact in your company. The result is confirmed only during a pilot.
Today
Current assumption: 108 h/month (9 h/start)
With the system
After scenario: 54 h/month (4.5 h/start)
Time or cost saved
Modelled scenario: 40-70 h/month, 54 h base case
- Volume
- Modelled scenario: 12 project starts/month
- Formula
- 12 x (9 - 4.5) h = 54 h/month
- Calculation status
- low-medium
Data in the screenshots. The names, amounts, and documents shown in the screenshots are synthetic. Client data remains private. Measurements describe the demonstrator and are kept separate from production outcomes.
Working surfaces
The delivery lead resolves disputed dates and seals the plan version; assembling the packet happens before they arrive.
The delivery lead opens one room: four sources with their hashes and a copy marked as a copy, commitments with their place in a file, a plan in three lanes, and a list of open points. The disputed dates stand side by side with their citations, so the client call starts from the question that has to be asked rather than from a plan that merely looks certain. The version seals after the resolution and leaves a record behind: who, when, and on what basis. How many hours a given team wins per project start has to be measured on its own volumes; the figures in the arithmetic beside this are a modelled scenario awaiting a before-and-after measurement.
Three screens: sources, commitments, plan version.
Sources
The packet files with their hashes and the copy marked as a copy, each openable in the original.
Commitments
Dates and conditions with their place in a file, the disputed pair written out in full.
Plan version
Actions in three lanes citing their commitments; sealing waits for the resolution.
System screens
See how the system works in practice
These desktop and mobile screenshots come from the running application. They show the process and the points where a person makes the decision.
- Screens
- 7
- px
- 1440 · 390
- 021440×1100
Two dates with quoted sources and the decision gate disabled without an authenticated role. - 031440×1100
The conflict on mobile with the synthetic scope visible.
Open the remaining screen archive (4)
- 041440×1100
Different files, identical content - 051440×1100
Two dates leading to one action - 061440×1100
The blocked plan version - 071440×1100
The packet-assembly chain
Technology stack
This process is won by parsers you can trust byte for byte; orchestration would be ballast here.
The route from file to gate is deterministic, so the stack stays short. It uses an RFC 822 parser, a pinned `pdf-inspector` revision, and PostgreSQL to enforce the data shape through foreign keys and closed value lists. No orchestration layer is needed because there is no loop, only a repeatable sequence that can be compared with the record. The language model sits outside the API in a separate local evaluation of Bielik 4.5B at 8-bit quantization. It answered in a median of 508.517 ms on Apple Metal in the documented test run; that measurement does not carry over to the target vLLM on NVIDIA. For maintenance and audit, every check is rerun with one command and compared with the previous record.
- Python `email` with policy.default
- reads an RFC 822 file and keeps its Message-ID and message body
- pdf-inspector 0.7.0, revision 20f24d1
- classifies the PDF and extracts its text locally, without sending the document anywhere
- PostgreSQL 17
- commitments, actions, disputes and the audit chain, with closed value lists
- FastAPI with psycopg
- assembles the packet and holds the gates: with a dispute open it refuses to seal the plan version
- Next.js 16 and React 19
- the working room: sources, commitments, the plan in three lanes, and the event history
- Bielik 4.5B v3.0 Instruct, MLX 8-bit
- a separate local eval of three controlled prompts, outside the API path
The client takes over the code, the database schema, the evaluation data and the documentation. The reference implementation runs as four Docker Compose services with explicit memory limits: the database sits on an internal network, the API serves only files from a list held in the database, and the system sends nothing outward and creates nothing in the client's tools.
Technical details and measurements
The working loop
A plan does not grow out of retyping. It grows out of commitments you can trace back to a file.
From file through commitment to action runs a chain of references you can walk in both directions: from an action to its commitments, from a commitment to its place in a file. A contradiction stops that chain in plain view rather than dissolving into it.
The kickoff packet: mail thread, forwarded copy, PDF and note
Parser and inspector → commitments with their place in a file
Forwarded copy → same content hash, one confirmation
Two go-live dates → an open dispute holds the plan version
Named resolution → a separate record sealing the version
System architecture
An RFC 822 parser, a PDF inspector, content deduplication and the dispute gate.
Standard file formats at the entrance, commitments with source locators, deduplication by normalized content hash, and an open dispute as the block on sealing a version.
- 01
Input
EML and PDF enter as files.
The Python `email` parser with `policy.default` reads an RFC 822 file and keeps its Message-ID and body. `pdf-inspector` at a pinned revision classifies the document, picks the reading route and extracts text locally, and we compute SHA-256 for every file.
- 02
Commitments
Every commitment carries a source and a locator.
Dates, scopes and conditions exist as separate facts with a source id and a place inside it: `body:2`, `page:1`, `sentence:3`. Actions in the plan carry the ids of the facts they follow from.
- 03
Duplicates
A forwarded copy shares its content hash with the original.
The copy has different bytes and a different file hash, but the same normalized content hash, so a thread forwarded three times stays one confirmation. The count of unique sources does not grow with forwarding.
- 04
Dispute
A contradiction closes the route to sealing a version.
Two `go_live` facts with different values form an open conflict, and an attempt to lock the plan version returns HTTP 409. In production an authenticated role records the resolution and the lock; the reference implementation refuses both writes with HTTP 403, because it has no identity and no role control.
Why no model sits in the path
Every step in this room is decidable without guessing: parsing, a hash, a comparison of two values in the same field. A model would add variance and cost here while removing the ability to reproduce a result down to the hash. Each component needs an auditable purpose, so the only model in the repository sits in a separate local eval outside the API.
- The file-to-action chain can be walked in both directions
- Forwarded copies never multiply confirmations
- An open dispute over the go-live date holds the plan version
- The hash chain detects a changed stored event
Want to assess a similar process in your company?
- A 30-minute call with the engineer who would lead the work.
- A review of the processes that cost you the most time and money.
- A written summary of what to automate first and the likely cost range.
Times are shown in your own time zone. We work with clients across time zones.
The scan is free and creates no obligation. If automation is unlikely to pay off, the written recommendation will say so.