The problem with templates
Most low-code platforms offer templates. You pick one, the platform copies it into your workspace, and from that moment it is yours. That sounds generous, and it is a trap. The copy has no relationship to the original. When the template author fixes a bug, adds a compliance field or improves an accessibility issue, your copy does not know. When you want to know whether your application still matches a certified baseline, there is nothing to compare against. A template is a one-time gift of a starting point, and every hour you invest afterwards moves you further from anything you could upgrade.
For organisations that need to demonstrate that a system implements a mandated process, this is a serious weakness. The certification, if there was one, applied to the template on the day you copied it. It says nothing about what you are running now.
What a solution pack contains
A Peek solution pack is a complete, versioned application model. It is not a project skeleton or a collection of screens. It contains everything the deterministic compiler needs to produce a running application in the Interact runtime.
- Data model: entities, fields, relationships, validation and indexes.
- Workflows: stages, transitions, assignments and service-level clocks with escalation.
- Rules and decision tables: eligibility, routing, fees and outcomes as inspectable tables rather than code.
- Pages and personas: what each role sees and can do, from applicant to supervisor.
- Automations: scheduled jobs, reminders and notifications run by the background worker.
- Integration stubs: typed connectors for common systems of record and signed webhooks.
- Ghost sample data: realistic synthetic records so the app is usable the moment it is installed.
- Tests: assertions about the workflow and rules that run before every publish.
Versioned and immutable
A pack has versions, and each version is immutable once released. When a workspace installs a pack, it records which version it started from. When the team adapts the pack in Studio, they produce their own versions that are also immutable once published. The relationship between the pack version and the workspace version is preserved, which is what makes upgrades possible.
When a new pack version is released, Studio can compute the difference between the pack baseline the workspace started from and the new baseline, and separately the difference between that baseline and the workspace's own changes. The result is a three-way merge presented as a set of proposals: apply this upstream change, keep your local change, or resolve a conflict. Because everything is a model rather than generated code, the merge operates on typed elements such as fields, stages and rules rather than on lines of text.
The deterministic compiler
Versioning only means something if a version has a single, predictable behaviour. Peek Platform compiles an application model to a runtime definition deterministically: the same model always produces the same output. There is no hidden state, no runtime interpretation that depends on what happened to be deployed before, and no code generation step that a developer can edit and drift from the model.
This property has practical consequences. A reviewer can read a model diff and know what the release will do. A test that passes against a version will pass against the same version anywhere. Two tenants running the same pack version are running the same application, which is what makes certification of a pack meaningful rather than aspirational.
Certification
A certified pack is one whose version has been reviewed against a documented checklist: the data model handles the required fields, the workflow implements the mandated stages and deadlines, the rules match the published policy, the pages meet accessibility requirements, the tests cover the critical paths, and the Ghost data exercises the edge cases. Certification is recorded against the exact pack version, and because the compiler is deterministic, it applies to every installation of that version.
When a workspace adapts a pack, the certification does not automatically transfer to their version. Studio does, however, show which certified elements are unchanged, which are changed and which are new, so an organisation can scope its own review to the delta rather than the whole application.
Why this changes the economics
Templates make the first week cheap and every following month expensive, because maintenance falls entirely on the customer. Versioned packs shift that curve. Upstream improvements arrive as reviewable proposals. Compliance updates can be applied across many installations. The cost of keeping an application current becomes proportional to how much you have diverged from the pack, and Studio shows you exactly how much that is.
For a contractor delivering similar systems to multiple agencies, this is the difference between maintaining a dozen forks and maintaining a small set of local adaptations on a shared baseline.
Where packs come from and where they are going
Today, packs are produced by Peek from government pilots and published in the marketplace. The pipeline from pilot to pack is described in its own post. The next step is to let organisations publish their own modules, so a contractor or an agency can maintain a certified baseline for the processes they own and distribute it to the teams that need it. The versioning, compiler and certification machinery already supports that; the remaining work is the publishing and review interface.
Key takeaways
- Data model: entities, fields, relationships, validation and indexes.
- Workflows: stages, transitions, assignments and service-level clocks with escalation.
- Rules and decision tables: eligibility, routing, fees and outcomes as inspectable tables rather than code.
- Pages and personas: what each role sees and can do, from applicant to supervisor.
- Automations: scheduled jobs, reminders and notifications run by the background worker.
- Integration stubs: typed connectors for common systems of record and signed webhooks.
- Ghost sample data: realistic synthetic records so the app is usable the moment it is installed.
- Tests: assertions about the workflow and rules that run before every publish.