A numbering resource, licence, asset or organisational record can look simple in a spreadsheet. The difficult questions arrive when somebody asks who may change it, which rule applies, what happened before and whether the current state can be explained. Those questions belong in the design brief.
Separate identity from allocation
An illustrative registry might hold a resource record, an organisation record, an application and an allocation. A resource keeps its identity when its allocation changes. Treating all four as one row makes later changes harder to describe and review.
Write the rules before the screens
Establish the permitted states, required fields, valid relationships and decision responsibilities. PostgreSQL’s constraint documentation explains how primary keys, unique values and foreign keys can enforce parts of that structure. Business rules that span records still need an appropriate transactional design and acceptance tests.
Give changes their own history
A current-state field answers what is true now. A change record answers what happened, when, who was responsible and which evidence supported the decision. Agree which events need to be recorded and how corrections are made. An audit history should help an authorised person understand the record.
Make permissions specific
Preparing a request, reviewing it and approving a change may belong to different responsibilities. Define those actions against the relevant records. OWASP recommends denying access by default and checking authorisation on every request; hiding a button in the interface does not provide that control.
Test a difficult example
Use representative sample records to walk through allocation, amendment, rejection and correction. Include duplicates, missing source references and an attempted change by somebody without permission. The result of the exercise should be a clearer rule or a visible unresolved decision.
Agree the operating evidence
Before release, identify the data dictionary, migration reconciliation, access matrix, acceptance scenarios and recovery procedure that the operating team will receive. A working screen is one part of the handover.
This is an illustrative design approach, not a description of a completed regulatory deployment. A commission needs its own source data, governing rules, decision owners and acceptance conditions.
Take it into the brief
A practical checklist.
- Separate resources, applications and allocations where they represent different things
- Define record identities, valid relationships and permitted state changes
- Agree who can request, review and approve each action
- Keep source references and important change history attached
- Test duplicate, invalid, unauthorised and correction scenarios
- Confirm the migration, acceptance and recovery evidence
Further reading.
Primary references checked 1 November 2026. The design approach above is the studio’s own explanatory guidance.
Continue the conversation
Have a related piece of work?
Bring the process, source material and constraints. We can discuss the right starting point.
Start your brief ↗