WNI Registry: from an operational problem to a production system
How domain knowledge, observation of a public office's daily work and iterative development led to a multi-module Django system used by public administration.
Production system · continuously developed
60,000+lines of code
2,600+entries in the live system
403automated tests
83.5%overall v6 coverage
Project overview
Not a prototype, but a tool for everyday work
WNI Registry was created in response to scattered spreadsheets, manual workflows and the need for immediate access to current data. It brings supervised-activity registries, administrative decisions, inspections, laboratory results, documents and reporting into one application.
The system operates independently of ARiMR, can run inside a controlled local network and is developed through observation of the real work performed by operators, coordinators and management.
Starting point
The challenge was organisational, not merely technical
The information required to handle supervised activities was distributed across spreadsheets, documents and external sources. Every change had to preserve decision numbering continuity, administrative history and compliance with official procedures.
01
One source of truth
Unifying registries, statuses, decisions and history without losing source information.
02
Administrative workflows
Representing WNI assignment, decisions, suspension, removal and reactivation.
03
Quality and accountability
Numbering audits, permissions, operation history, import validation and backups.
04
Usability
An interface suitable for daily work by users with different levels of technical experience.
Working method
Development driven by a short feedback loop
Modules were not built from an abstract feature list. Each stage began with a real user problem, data analysis and procedural constraints, and ended with observing the solution in practical use.
01
Process analysis
Mapping the real workflow, exceptions and user responsibilities.
02
Data model
Designing relations, statuses, change history and integrity rules.
03
Implementation
Building the Django module, forms, permissions and user interface.
04
Verification
Automated tests, viewport audits and validation against production-like cases.
05
Post-deployment growth
Corrections and new capabilities derived from everyday system use.
Architecture
A modular system deployed on the organisation's infrastructure
The application is accessed through a browser and can run exclusively inside a local network. The domain layer separates registries, inspections, documents and imports, while PostgreSQL stores a consistent view of the data.
Data and documentsPostgreSQL · Excel/XLSX · PDF · import files
↓
OperationsRoles · change history · audits · backups
System scope
Modules connected by a shared data model
01
WNI registries
Search, statuses, history, related activities and the complete entry lifecycle.
02
Decisions and documents
Numbering, templates, PDF decisions, applications and protected bulk correspondence.
03
SPIWET inspections
Protocols, results, irregularities, follow-up actions and period reports.
04
Annual plans
Inspection scopes, baseline counts, percentage targets and automatic progress calculations.
05
Imports and laboratory results
Validated Excel/ARiMR imports and Salmonella results matched to WNI entries.
06
Exports and analysis
Configurable Excel datasets, management indicators and data quality controls.
Design decisions
Data safety took priority over convenient shortcuts
Infrastructure independence
The system can run locally without sending entity data to the author's infrastructure.
Preview before import
Files are analysed before saving, with new, changed and problematic records clearly identified.
History instead of overwriting
Important changes remain accountable, and archiving does not remove links or past results.
Domain-aware permissions
Access depends on the user's role, assigned categories and operational responsibility.
Quality
Tests cover business rules as well as interface behaviour
In an administrative system, an error may mean more than a broken screen: it can also produce an inconsistent decision number or an incorrect document. Quality control therefore covers domain logic, imports, permissions and multiple viewports.
403 automated tests in the analysed v6 release.
83.5% total code coverage in that release.
96/96 completed view–viewport audit combinations.
Data integrity and decision-number continuity checks.
Outcome
One current view of the data instead of independent files
The system shortens the path from finding an entity to completing an operation, connects operational data with reporting and allows new modules to grow without splitting information into additional spreadsheets.
Fast search by WNI, personal or tax ID, producer, activity, category and status.
Documents and datasets generated without re-entering existing information.
A shared dashboard for staff, coordinators and management.
Plan progress and reports calculated from operational records, not manual summaries.
Product evolution
The system grows together with its users' processes
Core registry
Centralised entries, categories and statuses.
Decisions and documents
Numbering, PDF generation and operation history.
Imports and synchronisation
Validation of spreadsheets and external exports.
Inspections and plans
SPIWET workflows, annual supervision scopes and progress measurement.
External laboratory results
Salmonella results connected directly to WNI entries.
Ongoing development
Further capabilities based on production use and user feedback.
The system in practice
Selected screens from the production application
Decision numbering auditAnnual inspection plansInspection reportingConfigurable data export
WNI Registry remains under active development
The source code is private due to the nature of the solution and data protection. The commercial offer describes the product scope, deployment and licensing.
