Pilots are where the truth is
Process documentation describes how a process is supposed to run. A pilot shows how it actually runs: which fields are always blank, which approval step is a formality and which one is where the real decision happens, which deadline is enforced and which is aspirational, which integration is reliable and which one needs a manual fallback. This knowledge lives in the heads of the people who run the process and rarely makes it into a specification.
Building the pilot in Studio, with the team that owns the process, is how we capture it. The data model, workflow, rules and pages are edited in front of the people who know the answers, and every correction they make is a fact about the process that a template written from documentation would have missed.
Stage one: build the pilot as a real application
A pilot in Peek Platform is not a mock-up. It is a real application in a real tenant, published to the Interact runtime, used by real staff on real or realistic cases. The workflow has service-level clocks that actually run. The rules produce actual outcomes. The background worker sends actual reminders. This matters because the difference between a prototype and a production system is exactly the set of details a pack needs to capture.
During the pilot, the model goes through many versions. Because versions are immutable and the compiler is deterministic, we can look back at any point and see what the application did that week and why the team asked for a change.
Stage two: separate the general from the specific
Once the pilot is stable, we review every element of the model and classify it. Some elements are universal to the process type: a permit has an applicant, a location, a review stage and a decision. Some are jurisdiction-specific: fee schedules, statutory deadlines, the exact list of required documents. Some are local to the pilot team: the name of their document management system, the email footer, the order they prefer fields on a screen.
The pack keeps the universal elements as-is, turns jurisdiction-specific elements into configurable parameters with sensible defaults, and removes the local elements or leaves them as clearly marked extension points. Getting this classification right is the hardest part of the pipeline and the part most worth doing slowly.
- Universal: kept in the pack as core model elements.
- Jurisdiction-specific: exposed as parameters, decision tables or rules the installing team edits.
- Local: removed, or preserved as an example in the Ghost data and documentation.
Stage three: rebuild the sample data
A pack ships with Ghost sample data so that an installing team can use the application immediately. Real pilot data cannot be used for this, and simply anonymising it is neither sufficient nor safe. Instead, we write generators that produce synthetic records matching the shapes, distributions and edge cases observed in the pilot, without any real values. The Ghost data is versioned with the pack and regenerated whenever the model changes.
Good Ghost data is also a test fixture. It exercises the rules with cases that sit on thresholds, the workflow with cases that miss deadlines, and the pages with names and addresses that are long, short, or contain characters that break naive layouts.
Stage four: write the tests and the checklist
Every pack carries tests that run before any publish. They assert that the workflow reaches the expected stages under the expected conditions, that rules produce the expected outcomes for the Ghost cases, and that the pages expose the required fields to the right personas. The tests are written against behaviours the pilot team confirmed, so they encode what the process is supposed to do rather than what the current implementation happens to do.
Alongside the tests, we write the certification checklist for the pack: the requirements the pack version has been reviewed against. The checklist becomes part of the pack's published record and is what certification refers to.
Stage five: publish and version
The pack is published to the marketplace as version one. From that point, changes go through the same versioning discipline as any application: each release is immutable, each is compiled deterministically, each carries its certification status. When a second agency installs the pack and runs a pilot of their own, the classification exercise repeats: what they needed to change tells us which elements we classified wrongly, and the corrections become version two.
Installing teams who adapted version one receive version two as a set of upgrade proposals in Studio. They can adopt the improvements while keeping their local changes, which is the point of the versioned model approach.
What we owe the pilot teams
None of this works without teams willing to run a real process on a new platform and tell us when it is wrong. We do not name pilot partners without their permission and we do not publish anything from a pilot beyond the generalised model. What we can say is that every pack in the marketplace exists because a team somewhere did the hard part, and that the pack is our attempt to make sure the next team does not have to.
If your agency or organisation runs a process you think should be a pack, or you want to adapt one that already exists, write to [email protected].
Key takeaways
- Universal: kept in the pack as core model elements.
- Jurisdiction-specific: exposed as parameters, decision tables or rules the installing team edits.
- Local: removed, or preserved as an example in the Ghost data and documentation.