Where we started
The first version of Peek did one thing: it took a spreadsheet or a JSON export and produced a chart with an AI-written explanation. It was a good demo and a useful utility. It was also a product that stopped exactly where the interesting problems began. Once a team had a chart, the next question was always operational. Who owns the number? What happens when it crosses a threshold? Which case, application or inspection does it belong to, and who is allowed to act on it?
When we ran pilots with government teams, those questions dominated the conversation. Nobody was short of visualisations. They were short of systems that could take a request, route it through the right people under a service-level clock, record every decision, and survive an audit. The tools available to them were either bespoke builds that took quarters to deliver or general-purpose low-code platforms that treated governance as an add-on module.
What the pilots taught us
Every pilot produced the same artefacts in different clothing: a data model with a handful of core entities, a workflow with stages and deadlines, a set of rules that decided eligibility or routing, a small number of screens per persona, and an integration or two with an existing system of record. The domain details differed. The structure did not.
We also learned what teams did not want. They did not want an AI that quietly changed a record. They did not want a builder that let a developer redefine a schema in production without a trail. They did not want a shared database where a query mistake could expose another organisation's data. Each of these concerns maps to a specific architectural decision, and none of them can be bolted on convincingly after the fact.
- Applications in this space share a common shape: model, workflow, rules, pages, personas, integrations.
- Governance requirements are architectural, not cosmetic; they have to be designed into the core.
- AI is welcome as an assistant and unwelcome as an unsupervised actor.
The decision to rebuild rather than extend
We considered extending the charting product with workflow features. The honest assessment was that the data model, permission model and deployment model of a charting tool are wrong for a system of record. Charts are disposable; cases are not. Charts can be regenerated; a decision on a benefits application has to be reproducible years later. Extending the old product would have meant carrying design decisions that were optimised for speed of exploration into a domain that prizes correctness and traceability.
So we rebuilt. Peek Platform is a new codebase with a new set of primitives: tenants with row-level isolation, versioned immutable application models, a deterministic compiler from model to runtime, a hash-chained audit ledger, a metered usage ledger, and a background worker for schedules, SLAs, email and signed webhooks. The old product informed the tone and some of the interface conventions. Almost nothing else carried over.
What "governed" means in practice
Governed is an overused word, so it is worth being concrete. In Peek Platform it means that every application is described by a model that is versioned and immutable once published. It means the same model always compiles to the same runtime, so a reviewer can reason about what a release will do before it ships. It means every change to a record, a model, a permission or a domain is written to an audit ledger whose entries are hash-chained, so tampering is detectable. And it means that AI output never becomes state without a person approving it.
These properties are not features you enable. They are the only way the platform works. A tenant cannot opt out of isolation. A publish cannot bypass versioning. Sigma cannot skip the approval gate. Removing the option to do the wrong thing is, in our experience, the most reliable form of governance.
Solution packs instead of blank canvases
The second big shift is where a new application starts. A blank canvas is flattering to the tool and expensive for the customer. Instead, Peek Platform ships solution packs: certified modules distilled from real government pilots. A pack contains a data model, workflows with SLAs, rules and decision tables, pages, personas, automations, integration stubs, Ghost sample data and tests. A team installs a pack, adapts it in Studio, and publishes a version.
Packs are the reason the pilots mattered. Each one was an opportunity to observe how a process really runs, encode it, and generalise the parts that were not specific to one agency. We write more about that process in a separate post on turning pilots into packs.
Studio, Interact and the Console
The platform has three surfaces. Studio is the visual builder where a team edits the data model, workflows, rules, pages, personas, automations and integrations, seeds Ghost sample data, runs tests, manages versions and publishes. Interact is the runtime that serves published applications to end users with the tenant's branding, on a Peek subdomain or a custom domain with automated TLS. The Console is where an organisation manages workspaces, members, single sign-on, domains, usage and billing.
Sigma AI is present in each surface but always in the same posture: it proposes, and a person decides. In Studio it drafts blueprints from a description and suggests changes to a model. In Interact it produces summaries and insights on records. In the Console it flags anomalies in usage. In every case the output waits in a review queue until someone accepts, edits or rejects it.
What happens to the old product
The charting features are retired. Existing accounts continue to work and now land in the Console, where they can create a workspace and start from a pack on the Free plan. We know a pivot like this is inconvenient for people who liked the old tool, and we would rather be direct about it than pretend the two products are the same thing.
If you are building or procuring case management, licensing, inspection, grants or service-request systems and want a platform where governance is the default, we would like to hear from you at [email protected].
Key takeaways
- Applications in this space share a common shape: model, workflow, rules, pages, personas, integrations.
- Governance requirements are architectural, not cosmetic; they have to be designed into the core.
- AI is welcome as an assistant and unwelcome as an unsupervised actor.