Skills in action / Document life cycle
A small application that runs the life cycle of policies, standards, guidelines and procedures, and a way to teach it by doing.
In every data governance programme, the first deliverables are documents: a policy, quality standards, roles and responsibilities, procedures for access, retention or incidents. They are written by business experts, reviewed by peers, approved by a board, and everybody must know them and review them every year. Then comes the question that came back on every assignment: where do these documents live, and who runs their life cycle? The answer was usually a shared folder and a spreadsheet, a SharePoint library with a flow nobody dared to touch, or a product the client could not justify for a few dozen documents.
Promulga is my answer: the governance of governance documents, simple enough for Data Owners, who are rarely IT people, and rigorous enough for an auditor.
The flow is deliberately fixed, so that everybody learns it once. Only the timing is configurable: by default 4 weeks to draft, 2 to review, 2 to revise and 2 to approve, with reminders when a deadline is near or missed.
| Who | What they do |
|---|---|
| Document Manager | Creates the document, chooses its type, tags and people, follows the register and unblocks a stuck review. |
| Owner | Checks out the Word file, writes it, checks it in, answers the comments and submits it. |
| Reviewers | Comment on one shared version and click Review done. |
| Approvers | All must approve; a single rejection, with a mandatory comment, sends the document back to the owner. |
| Promulga | Converts the approved file to PDF, stamps every page with reference, version and date, fingerprints it (SHA-256), publishes it on the portal and notifies everyone. |
Authors keep their tool; every check-in is kept as a revision. An online editor is optional.
One working version, then one official, versioned PDF; earlier versions remain available.
Every action, by whom, when and with which comment, exportable as CSV.
Periodic review dates, read & acknowledge with tracking, and indicators such as the on-time rate.
Published documents can be browsed through tag hierarchies and searched, by everyone or only by signed-in readers.
The diagram shows who does what, and when the timers act. It is the same flow for every document, which is what makes it easy to teach: five lanes, one path, one rejection loop.
Dashed arrows are the timers: reminders when a deadline is near or missed, and a periodic review that starts a new revision.
A tool does not make a policy: it applies one. Before the first document goes through, a governance framework has to decide a few things, and Promulga makes each of them a setting rather than a habit.
| What the document policy decides | In Promulga |
|---|---|
| Which types of documents exist (policy, standard, guideline, procedure…) | Document types, each with its reference prefix (POL-0007, STD-0012) |
| How documents are classified and found | Tag hierarchies (domain, regulation, audience), shown on the public portal |
| Who plays which role, and who must not play two | Owner, reviewers, approvers, Document Manager; a warning when the owner also approves |
| How long each stage may take | Durations per stage, reminders when due soon or overdue |
| What an approval means | Every approver must approve; one rejection, with a comment, returns the document |
| What counts as the official version | One stamped, fingerprinted PDF per version (major.minor); earlier versions stay available |
| How a document stays current | Mandatory change note, periodic review date, read and acknowledge with tracking |
| What must be provable | An audit trail of every action, exportable as CSV |
This is the draft, review, approve and publish flow that I put in place in governance programmes (see the method). Here it can be played, and changed in the settings.
Learning document governance from slides is abstract. Playing it is not. Promulga ships with a 15-minute demo scenario in which the participants take the roles in turn: the reviewer comments a policy, the owner resolves the comments and resubmits, the approver approves, and the document appears on the portal with its stamped version 1.0. Everybody then sees, on the same screen, what a deadline, a reminder, a rejection or an audit trail means.
What is expected of an owner: a clear scope, a change note, answers to the reviewers, and a periodic review.
How to comment on one shared version, and why every approver decides and one rejection is enough to send it back.
How to design the document types, the tags and the roles, and how to follow the register and the indicators.
How a documentary framework (policy, standard, guideline, procedure) becomes something people can find and trust.
This is how I use it in coaching: the same flow of draft, review, approval and publication that my approach puts in place, made tangible. It runs on a laptop, and the data of a demo can be reset in one command.
It is a Python application with two sites in one: a public portal to find and read the published documents, and a workspace for the people in the workflow, with sign-in by passkey, e-mail and password, or single sign-on. It runs self-hosted with Docker, so your governance documents stay on your own server.
Python 3.12, FastAPI, SQLAlchemy (SQLite by default, PostgreSQL optional), Jinja2 templates without a JavaScript framework, APScheduler for reminders, Gotenberg (LibreOffice) for the PDF conversion, pypdf and ReportLab for the stamp, Caddy for automatic HTTPS, Alembic for migrations, pyHanko for optional electronic seals, and OnlyOffice Docs (optional) for online editing. The interface follows WCAG AA contrasts and uses a self-hosted font and icons, with no third-party request.
Visit promulga.com Code and documentation on GitHub Contact me