Document Lifecycle
A document is not valid because it was uploaded β it is valid because it completed its lifecycle. The system drives that lifecycle as a state machine and records every transition, so the approval history is auditable rather than reconstructed from memory.
Each stage creates tasks for the responsible identities. You act on a document through your task, not by editing the record directly.
The pipelineβ
| Stage | Who acts | What happens |
|---|---|---|
| Draft | Owner | The document is editable. Nothing is distributed and no reader sees it as valid. |
| Opinion | Opinion providers from the matrix | Reviewers submit an opinion. This is a consultation stage β it does not approve anything. |
| Control | Controllers | A technical/formal check. Any one controller's action moves the stage forward; there is no ordering between controllers. |
| Approval | Approvers from the approval matrix | Stepped and sequential β see below. |
| Published | β | The document becomes the valid version. Distribution, controlled-copy tasks and the review cycle all start here. |
| Cancelled | Owner, via a cancellation request | The document stops being valid. |
If the folder is marked approval free, the approval stage is skipped entirely.
Sequential approvalβ
The approval matrix is organized in steps. Approval is gated:
- Only the approvers in the current step receive a task.
- Every approver in that step must approve before the next step opens.
- The document publishes only after the last approver of the last step has approved.
A rejection at either control or approval sends the document back to draft, with the rejection reason recorded.
What happens on publicationβ
Publication is more than a status change. When the document enters the published state, the system:
- Stamps the published date.
- Bakes the
{{Token}}placeholders in every language file and stores a PDF rendition of each. - Creates the read tasks for the distribution matrix.
- Grants read authorization to the distribution targets.
- Creates one controlled-copy task per distribution point.
- Calculates the first review date, if review is enabled.
- Deactivates the previous revision in the same chain, so exactly one revision is valid at a time.
Steps 2 through 7 run as a background job. The published date appears immediately; the rest can take a few moments on a document with many language files.
Approval historyβ
Every action in the pipeline β opinion submitted, controlled, approved, control rejected, approval rejected β is written to the document's activity log against the person who actually acted, not the role that was assigned. This is what makes delegation traceable: if a task was assigned to a position and a specific person acted on it, the log shows that person.
The history is visible on the document's view page, and can be baked into the document content itself through placeholder tokens.
Cancelling a documentβ
A published document is cancelled through a cancellation request:
- Any user opens a request from the document view page, giving a cancellation reason.
- The document's owners receive an approval task.
- On approval the document moves straight to cancelled, and the system automatically opens a revision request against every other active document that referenced it.
- Any other open cancellation request for the same document is cancelled automatically.
Multiple cancellation requests may be open against the same document at once; the first approval settles it.