Organisation building and cadre management for a military programme

The situation

A military organisation-building programme needed to replace something that was not a system at all. Organisation structures were maintained in documents, cadre files were kept on paper with photographs attached, appointment and transfer records were spread across whoever had last updated a list, and statistics were assembled by hand whenever a return was due.

The requirement looked like a records database: organisation units, cadre files, appointments, statistics. The difficult part was that three different questions were being asked of the same people — what the organisation looks like, what an individual’s career looks like, and what the aggregate looks like at a point in time — and a records database usually answers only the first two well.

The call we made

Model the organisation separately from the person, and model appointments as dated events. Everything else depends on this.

If the unit a cadre belongs to is stored as a field on the cadre record, then the moment someone transfers, the history is gone: the record now says the new unit and there is no way to ask who held the old post last year. The same happens if the post is stored as a field on the person. So the organisation tree stands on its own — units, party organisations, hierarchy — and a person’s relationship to a post is an appointment record with a start and an end. A transfer closes one appointment and opens another. Nothing is overwritten, and a reorganisation does not erase the record of what the organisation was.

Once that model exists, statistics stop being a separate exercise. Headcount by unit and rank, and one cadre’s service history, are two queries over the same data, and a figure in a return can be traced back to the appointment records that produced it. That was the point of the build: the value is not the form that captures a cadre’s details, it is the fact that the report and the record agree, and keep agreeing after the next round of postings.

Records and photographs are part of the master data. A cadre file without its photograph is incomplete for this customer, so the archive was built as an indexed, searchable store rather than an attachment field on a form. Digitisation only pays off if retrieval is faster than the paper it replaced.

Permissions follow the unit, not the role alone. Data is separated by unit so that a user sees their own organisation’s records; a role does not grant the whole database. Export exists because reporting upward still happens through documents, but the export is bounded by the same rule, which was the part the customer checked first.

What we built

Organisation structure and party-organisation records, maintained as a hierarchy with a module-based home screen as the single entry point.
Cadre files including photographs, with a searchable archive rather than a folder view.
Appointment, transfer and service-history records as dated events, so both an individual career and a post’s occupancy can be reconstructed.
Multi-dimensional statistics by unit and rank, generated from the records rather than entered separately.
Unit-level data isolation with graded authorisation, so access is bounded by the organisation the user belongs to.
Export for upward reporting, subject to the same authorisation boundary.

Result

The programme’s records moved from dispersed paper and sheets into one maintainable source, and the three questions — structure, career, aggregate — are now answered from the same place. The practical change is retrieval: a cadre file that used to require finding a physical folder opens directly, and a statistical return that used to be assembled over days is a query.

The design decision that mattered most is the least visible one. Because appointments are events and the organisation is separate from the person, a reorganisation does not destroy history, and a return produced last year can still be reproduced this year. For an organisation whose structure changes regularly, that property is the difference between a system that stays true and one that has to be corrected by hand after every change.

If you are replacing paper personnel records, the question worth settling before the first form is designed is what the organisation will need to ask about the past, not just about the present.

Screens from this system are not published. It runs on client infrastructure with client data, so we show it live instead: a short screen-share walkthrough under NDA, on a system we demonstrate rather than a screenshot we sanitised. Ask for it in the first call.

Technology

Stack	Vue 3 · Spring Boot · MySQL · ECharts
Delivery model	On-premise delivery
Client	A military organisation-affairs programme (name withheld)
Status	Delivered

What we cannot show

Unit designations, cadre identities, photographs, appointment records and statistics are withheld. Interface screens from the delivered system are not shown.