Demo Scenario
Documented Scenario / Pilot PreparationCoordination and delivery of 20 standardized houses.
A documented end-to-end scenario for the first validation industry. It has not been run yet — this is what the pilot is designed to test.
01 — Project context
What the scenario covers.
Twenty standardized houses delivered in Denmark as one coordinated programme rather than twenty separate builds. The houses follow a repeatable design so that the same scenario, suppliers, production tasks and assembly sequence can be reused from one unit to the next.
House areas follow the Danish convention and are measured by outer perimeter, which is why they differ from internally-measured figures used elsewhere. The exact area per unit is confirmed against the project set before publication.
02 — The coordination problem today
The work around the work.
When twenty-five independent companies serve one programme, a second management system grows around the professional work. Each organisation separately maintains its own quotes, negotiations, documents, controls, reporting and handovers of information.
- Information is requested, then requested again in a different form
- Each company is briefed separately on the same task
- Offers arrive in incompatible formats and have to be normalised
- Changes are re-circulated by hand and reach participants late
- Responsibility is lost at the boundary between two companies
- The same clarification is repeated in every new project
The problem is not that people work badly. It is that the same management work is repeated inside every organisation.
03 — Participants and roles
Who the scenario connects.
Design, engineering, supply, production, logistics, assembly and inspection.
The people doing the professional work the programme exists to deliver.
Directors, project managers, lawyers, accountants and coordinators.
The programme window the baseline is measured across.
Participating companies are not named publicly until each has confirmed in writing that it may be listed.
04 — Existing systems and documents
What IPPA connects to.
The scenario does not replace the systems the participants already run. It reads from and writes back to them.
05 — Operational objects
What the scenario is built on.
Every action in the scenario attaches to a linked digital object rather than to a file or a mailbox.
06 — Connected centres
Only the centres the scenario needs.
A design change on this programme activates six of the eleven centres. The others are not involved, and the scenario does not pass through them.
All participating centres see the same change, its cause, its consequences, who is responsible and its approval state.
07 — End to end
From project data to a measured result.
08 — Human and AI responsibilities
Where each one acts.
AI
- Check completeness of a submitted set
- Detect version conflicts and contradictions
- Recalculate affected quantities and dependencies
- Route a change to the roles it affects
- Track deadlines and flag deviations
- Prepare a decision for a responsible person
Human
- Approve a technical change
- Accept a commercial condition
- Sign anything with legal effect
- Confirm a budget movement
- Accept delivered work
- Close a stage
Critical technical, financial, legal and management decisions are confirmed by an authorised person. The system prepares the decision; it does not take it.
09 — Approvals and verification
What counts as proof.
A task is not complete because someone says so. It is complete when the scenario holds evidence against it.
- Document or signed act
- Model or drawing version
- Photographic or site record
- Measured data from the process
- The identity of the person who approved it
- The time the approval was given
10 — Proposed interface
DefinedWhat the pilot needs on screen.
These screens are specified, not built. Building them is the next milestone, not an existing asset.
- Digital object card
- Active scenario view
- 11 centres and connected roles
- Task view
- Document and version history
- Parameter-change propagation
- Decision log
- Execution confirmation
- Role-based AI assistant
- Management dashboard
11 — Pilot metrics
What gets measured.
The pilot measures the same processes before and after, over a four-to-eight week window, and compares them.
12 — Target effect
Stated as a hypothesis, not a result.
Target hypothesis: a 25–40% reduction in measurable cross-company coordination time. To be validated during the pilot.
The baseline model assumes 4 800 management hours across the programme at an average full cost of 55 € per hour. Against that base, the target band corresponds to roughly 1 200–1 920 hours.
The baseline method and the measurement methodology are defined and agreed before the pilot starts. No higher figure is published until a real pilot has been measured. Nothing on this page is a delivered result.
13 — Current status and next milestone
Where this actually stands.
Written end to end, with its objects, centres, roles and metrics.
Participants, baseline, legal framework and measurement method being agreed.
Screens specified. Prototype is the next milestone.
Nothing measured yet. This is what the pilot produces.
14 — What investment is for
Turning the scenario into a measured pilot.
Investment converts the documented architecture into a working MVP, prepares this pilot and validates whether the target band holds in a real programme.