Documentation Governance with aprity
aprity generates the documentation, checks it against your org and publishes a new version after each analysis. Governance is what makes your team trust and use it: who starts the analyses, who reviews, who answers reader feedback, and what is checked before the documentation is shared.
Roles
| Role | aprity permission set | Responsibility |
|---|---|---|
| Documentation lead | aprity Admin | Starts the weekly analysis, checks coverage and fidelity, moderates reader feedback. |
| Business analysts | aprity User | Review business rules and processes of their area, give feedback. |
| Technical leads | aprity User | Review automation order, integrations and technical details, give feedback. |
| Readers | aprity User | Read the documentation, ask the Org Expert (Intelligence), flag errors. |
Only aprity Admin users can start an analysis and see the administration pages of the portal (for example Connectors and the moderation of Human corrections). Keep this group small.
A weekly routine
All plans allow one analysis per week. A simple routine:
- Start the analysis after the week's deployments (documentation lead).
- Check the version once published:
- Coverage and fidelity > Coverage: is anything missing? A version marked Partial documentation has gaps.
- Coverage and fidelity > Verification: read the fidelity score and the divergences.
- Coverage and fidelity > Versions: what changed since the previous analysis.
- Review the changes: business analysts and technical leads review new and changed rules in their area.
- Handle feedback: in Human corrections, look at what readers flagged and what the analysis did with it. Archive what is resolved or outdated.
- Share: send links to the pages that matter for the week's topics.
Review checklist
Before you share a version, check that:
- The version is not marked Partial documentation, or you explain its gaps.
- The fidelity certificate has no unexplained divergence on the pages you share.
- Business rules of your critical objects read correctly.
- Reader feedback from the previous week was handled.
Reader feedback
Every reader can flag a problem on a page or a rule. Define:
- Who answers: usually the documentation lead, with the business owner of the area.
- How fast: for example, before the next weekly analysis, so the feedback is taken into account.
- When to archive: once a correction appears in the documentation, or once the org has changed and the feedback no longer applies.
Organize with themes
Themes let your team group rules, objects and interfaces by business topic (for example "Invoicing" or "Customer onboarding"), across the whole documentation. Agree on a short list of themes and on who files items, so that the Themes page stays useful.
When to run an extra review
- After a major release (new objects, reworked automation).
- Before an audit or a migration workshop.
- When the fidelity score drops, or divergences appear on critical pages.
Maturity levels
- Ad hoc: analyses run when someone remembers; nobody reviews.
- Routine: a weekly analysis; the documentation lead checks coverage and fidelity.
- Governed: named reviewers per area; feedback handled every week; themes agreed.
- Embedded: the documentation is the reference in design and release reviews; the AI assistants (Intelligence) answer day-to-day questions from it.
Start at level 2 and move to level 3 once the team is used to the routine.