Decisions the public can look up

The situation

An authority takes applications from the public, checks documents, routes them for assessment and a decision, and publishes the outcome on a register that citizens and journalists read. There are statutory time limits. The fee schedule changes on a set date. Every decision has to be attributable years later, on appeal, and nothing still being drafted may ever appear on the public register.

These are illustrative scenarios showing how the products are used, not customer case studies.

What gets modeled

The structure as it would actually be defined — sections that repeat are marked.

How it gets built

In the order somebody would actually do it. Each step names the capability it rests on, so it can be checked against the product pages.

1. 1

   Model the application and its conditions

   Documents repeat, and so do the conditions attached to a decision — a licence can carry many, and the number is not known in advance. The decision section is written by the case officer, not the applicant, and the form reflects that.

   What it uses: Sections that nest and repeat to any depth

2. 2

   Take applications in through the API, work them in the screens

   Publishing gives the application its own REST URL space and a form and table rendered from the same definition. The public intake portal writes through the API; case officers work in the generated screens with typed filters and saved layouts.

   What it uses: Its own API on publish, plus forms and tables from the schema

3. 3

   Keep the case file from the first day

   History is enabled on the schema, so every write keeps a snapshot and the state of a case on a given date is a lookup. On appeal, what the file said when the decision was made is answerable rather than reconstructed.

   What it uses: Snapshot per write, restore to any retained point

4. 4

   Route the assessment against the statutory clock

   A trigger starts the assessment run when an application is created, with filters so that minor applications take a shorter path. Deadline warnings fire against the statutory limit and escalation moves a case on when it is at risk, rather than the limit being discovered after it passed.

   What it uses: Record triggers with filters, deadline warnings and escalation

5. 5

   Record the decision so it stands up on appeal

   The decision is a human decision step with your own outcome vocabulary and reason codes, and the decision chooses the outgoing path. Where the decision warrants it, signing requires re-authentication and the signature is chained so alteration is detectable.

   What it uses: Human decision steps with your own vocabulary, and chained signatures

6. 6

   Publish to the register, read-only, on purpose

   The register entry schema opts into anonymous read — reads only, with anonymous writes refused outright, and available only for schemas that publish on save. It is opted into per schema and never on by default, so the case file behind it stays closed while the outcome is public.

   What it uses: Opt-in anonymous read, per schema, reads only

7. 7

   Change the fees on the day they change

   A fee schedule change waits for an approver, then for the date the ordinance names. Until it is published it stays a draft, and the draft is held apart from the published version. A fee somebody has proposed is never what the public API hands out.

   What it uses: Publishing on approval and on a schedule, with separate draft and published states

Numbers used above, and where they come from

Every figure on this site is counted from the product itself. Nothing here is a performance or customer claim, because there is no measurement to cite for one.