System changes
A screen, field, permission, or workflow path changes after the procedure was approved.
The difference is what happens after publish.
Your procedures stay true to the systems they describe, and you find out before your people do. When a step goes out of date, the fix is waiting for review instead of quietly misleading the next person.
Rules change
A policy, regulation, requirement, or operating standard changes underneath the documented work.
People change the handoff
The informal handoff changes, but the SOP, video, course, or portal still teaches the old path.
See a validation run, start to finish.
A guide being checked against the live product, screen by screen: each step followed, the pause where it asks a person for a value it should not store, proof kept for every step that passes, and the result filed against the document.
The captured workflow itself: each step with the screenshot and the written explanation it was recorded with.
Validations run on a schedule. Results reach the team where they already are.
Your guides are checked on the schedule you set, and the outcome reaches your team in Teams, Slack or email. A pass needs nothing from you; a change arrives with the fix already drafted.
autopilot · validation schedule● on
- Nightlyevery day · 02:00
- After each releasetriggered by a deploy
- WeeklyMondays · 06:00
rotate database credentials · checked in your environment
nightly check · 02:00in your environment
- ✓open the credentials vault
- ✓request rotation approval
- ✗rotate and update the secret
- ✓re-run the connection check
step 3 changed · repair drafted
- Microsoft Teams#ops-runbooksRotate database credentials · step 3 changed · repair drafted · approve →
- Slack#docs-verificationRotate database credentials · step 3 changed · repair drafted · approve →
- Emailsop-owners@Nightly validation: 3 of 4 steps matched. Step 3 changed; a repair is waiting for your approval.
It runs without being asked
Put a guide on a schedule, nightly, weekly, or after each release, and it is checked without anyone having to remember.
The team hears about it where they already are
Results go to Teams, Slack or email: a pass, or a change with the exact step that no longer matched.
A person still decides
When a step changed, the corrected version is drafted for you. Nothing publishes until someone on your team accepts it.
All of this runs inside your environment, against whatever your procedures touch: web and desktop applications, internal services, cloud systems, databases, even local files. Your credentials never leave.
Verification questions, answered.
What is documentation verification?
It means your SOPs, guides and walkthroughs are checked against the system they describe, on a schedule, and you are told the exact step that no longer matches.
What does it mean when guidance is out of date?
Drift means the approved guidance is now out of date. A button moved, a field changed, a permission differs, a rule changed, or a handoff evolved while the published procedure stayed the same.
What happens when verification fails?
You are told which step no longer matches, a corrected version is drafted for you, and someone on your team decides whether it becomes the current version. Nothing changes on its own.
Can verification run inside our environment?
Yes. It runs inside your environment, using only the access you approve. Nothing sensitive leaves, and nothing has to be opened up to the internet.
What systems can InteractiveDox verify?
Anything the procedure touches: web applications, desktop applications, internal services, cloud systems, databases and local files. If your people can do it, it can be checked.
Does InteractiveDox automatically publish changes?
No. It drafts the correction; your team decides whether it becomes the current version.