E-Government

Modernising legislative information management

A legislative system has one job that matters above the rest: to be able to say, without ambiguity, what the current text of a measure is and how it got there.

By ITDC Systems Engineering Team · · 9 min read

Executive summary

Sanggunian secretariats run on documents and deadlines. The systems that replace their filing cabinets usually get the document storage right and the process wrong — which is the part that determines whether the secretariat uses the system or keeps a parallel spreadsheet.

Drawing on delivering legislative tracking for three local government units, this piece covers the modelling decisions that matter: measure versus document, the stage model, the voting record, and how much to publish.

The problem

A measure passes through readings, committee referral, amendment and enactment, accumulating documents at each step. Managed manually, the current version of an ordinance is whichever copy the secretary is holding. Answering “what stage is this at” means asking someone. Reconstructing how a member voted means reading minutes.

Constituents, meanwhile, have no route to the record except the secretariat, so routine requests for a copy of an enacted ordinance consume staff time that has nothing to do with legislating.

Technical discussion

Model the measure, not the document

The most consequential modelling decision is separating the measure from its documents. A measure is the thing with an identity, a number, a title, a sponsor and a current stage. Documents are artefacts attached to it: the filed text, the committee report, the amended text, the enacted version.

Systems that treat the document as the primary entity cannot answer the central question — what is the current text of this ordinance — because they hold six files with no authoritative relationship between them. Model the measure first and the version question becomes trivial.

Make the stage model configurable, then leave it alone

Every LGU's process differs in detail: number of readings, committee structure, how amendments are handled. Build the stage model as configuration rather than code, but resist making it arbitrarily flexible. A configurable list of stages with defined transitions covers the real variation; a general-purpose workflow engine is more than the problem needs and harder for the secretariat to reason about.

Numbering is harder than it looks

Measure numbering carries local convention: series by year, separate sequences for ordinances and resolutions, sometimes gaps preserved for historical reasons. Numbering also interacts with migration — historical records must keep their original numbers even where those numbers do not match the rule you are implementing.

Treat the number as data attached to the measure, not as a derived value, and provide an override with an audit entry.

The voting record

Record votes per member per measure as structured data, not as free text in the minutes. This is what makes the record reportable afterwards, and it is usually the feature the secretariat values most, because reconstructing a voting history from minutes is slow and error-prone.

Handle abstentions, absences and inhibitions explicitly. A member who was absent is not the same as a member who abstained, and conflating them produces a record that will eventually be disputed.

Decide the publication boundary deliberately

Publishing enacted ordinances and resolutions is straightforward and valuable. Beyond that, decide explicitly: are drafts public? Committee reports? Attendance? There is a legitimate transparency argument for more, and a legitimate argument that publishing drafts invites confusion about what is in force.

Make it a configuration decision the LGU owns, with a clear visual distinction in the public view between what is enacted and what is pending.

Migration determines whether it gets used

A legislative system that launches empty is a system the secretariat has to maintain alongside their existing files. Loading the historical register — even partially, even with imperfect metadata — is what makes it authoritative from the first day.

Architecture

Measure-centric, with documents as attachments and a public view derived from the same store:

Presentation
Secretariat workspaceCommittee viewPublic document searchSession console
Services
Measure & stage trackingDocument versioningAgenda & sessionVoting recordPublication rules
Data
Legislative registerDocument storeVote recordsAudit log
Operations
Retention policyBackup & recoveryAccess control

Recommendations

  • Model the measure as the primary entity; documents are versioned attachments to it.
  • Make stages configurable but bounded — a defined list with defined transitions, not a general workflow engine.
  • Treat the measure number as data, with an audited override for historical records.
  • Record votes as structured data, distinguishing abstention, absence and inhibition.
  • Decide the publication boundary explicitly and distinguish enacted from pending in the public view.
  • Migrate the historical register at launch, or expect a parallel paper process to persist.
  • Align retention with the LGU's records obligations from the start.

Conclusion

Legislative systems succeed or fail on whether the secretariat trusts them as the authoritative record. That trust comes from modelling the measure properly, migrating the history, and being unambiguous about what is in force.

Let's talk

Working on something like this?

If you are scoping a project in this area, we are happy to talk through the architecture and the implementation approach before anything is procured.