This is not an official U.S. federal government website. The Federal Modernization Workbook is independent technical analysis. It does not represent the position of, and has not been reviewed or endorsed by, any federal agency.

Training module · Draft

Ticket-to-Machine, Module 6: Actuation and the Re-read Rule

Let the ticket authorize a machine, then close the finding only when a re-read of the target shows the intended state

Research draft: Module 6 of the Ticket-to-Machine learning path. You learn how Gate 5 actuates by lane on the products themselves, how the business rule and the re-read client enforce Gate 6’s close-only-on-a-re-read rule, and run the re-read client’s offline mode over six waiting findings on two days. Guide Gates 5 and 6; workbook Chapter 05.

Modified

November 1, 2026

Status — Draft

This page is still being written. Expect gaps and changes; it is not part of the workbook's production guidance. Last reviewed 2026-11-07.

Learning path: Ticket-to-Machine on ServiceNow and SailPoint · Module 6 of 7 · 55 minutes · Guide Gate 5 and Gate 6 · Workbook Chapter 05

Watch: the narrated deck for this module: Deck · ▶ Watch (about 14 minutes, captions) · MP4 · Script · Captions.

Unit 1: Introduction

3 minutes, with the objectives and prerequisites

SailPoint’s Service Desk integration treats a provisioning task as complete when the mapped ServiceNow status says so. A technician sets a ticket to Closed, and nothing was checked. Book 13’s rule is that a success response isn’t closure: a finding closes only when a re-read of the target shows the intended state. In this module you see where the fix runs, and then you enforce the rule and watch the re-read client decide six findings.

The federal requirement. The guide’s Gate 5 table maps actuation to NIST SP 800-53 CM-5, AC-3, AC-6, CM-3, AU-14, CA-5 and NIST SP 800-63B-4; the Gate 6 table maps the re-read to CM-3, CM-4(2), CA-7 and AU-12. Chapter 05’s table says what each closure proves and who keeps it. Each table’s KSI column names the FedRAMP 20x Key Security Indicators to line your evidence up with; your cloud providers report against them, the agency doesn’t.

Learning objectives

In this module, you’ll:

Explain how Gate 5 actuates by lane, and why the kit has no test for it.
Describe what the business rule does with a close, and who can close a finding.
Run the re-read client offline and interpret verified, mismatch, pending and skipped.
Explain why a stale read waits, and why an empty intended state is never verified.

Prerequisites

Module 5, and Module 2’s ServiceNow roles, for the verifier.

Unit 2: Actuation by lane

8 minutes

The ticket authorizes a machine. SailPoint’s connectors provision owner-governed access; ServiceNow’s Entra ID spoke handles low-authority tasks where its actions cover them; disconnected applications run as declared exceptions; people act only through a just-in-time activation. The kit’s Pass 1 doesn’t actuate, so Gate 5 is configuration of the products themselves, with no automated check yet. Read:

The guide’s Gate 5 and its Validate (G5) step.
Book 13, Chapter 10: when no machine can reach the surface, for the declared-exception lane.

Unit 3: The business rule and the verifier

10 minutes

The business rule turns any close into Awaiting verification, unless the update carries new evidence and comes from the verifier account; a named exception approver can still cancel with a note. The re-read client reads each waiting record, re-reads the target through ISC or Microsoft Graph, and closes with the evidence or reopens with the differences. Read:

The guide’s Gate 6 and its Validate (G6) step.
Book 13, Appendix B: the five-clause request chain.
The implementation example’s Build 2.

Unit 4: The guard and the offline mode

10 minutes

Chapter 05 adds two things. The guard skips any record whose intended state names nothing a re-read can check, because comparing against it always “matches.” The offline mode runs the client’s decisions over saved records and saved reads, with the clock fixed, so you can test the rule with no tenant. Read:

Chapter 05: what this chapter adds, including the six fictional waiting records.
Chapter 05: dangers.

Unit 5: Exercise: Lab 1 (fixtures, no tenant)

17 minutes

Every command in Lab 1

Every command in this lab, in order, from examples/servicenow-sailpoint. Each step below says what it does and what to look for.

# Step 1
python -m pytest tests/python/test_reread_verification.py tests/python/test_reread_offline.py -q

# Step 2
python clients/python/reread_verification.py --records-json tests/fixtures/reread/awaiting_records.json --observations-json tests/fixtures/reread/observations.json --now 2026-11-01T12:00:00Z

# Step 3
python clients/python/reread_verification.py --records-json tests/fixtures/reread/awaiting_records.json --observations-json tests/fixtures/reread/observations.json --now 2026-11-02T12:00:00Z --out-json out/reread.json

# Step 4
node --test --test-name-pattern="redirected|verifier|exception approver|evidence alone|non-closing|SDIM" tests/servicenow/servicenow_scripts.test.js

# Step 5
rm -rf out

You re-read six waiting findings on two days and run the business rule’s tests. Work in examples/servicenow-sailpoint. Chapter 05, Lab 1 explains each result.

Run the re-read tests.

python -m pytest tests/python/test_reread_verification.py tests/python/test_reread_offline.py -q

Expected: 15 passed.

Re-read six waiting findings at noon on November 1.

python clients/python/reread_verification.py --records-json tests/fixtures/reread/awaiting_records.json --observations-json tests/fixtures/reread/observations.json --now 2026-11-01T12:00:00Z

Expected output:

[dry-run] IDF0001001: verified; would PATCH state=3
[dry-run] IDF0001002: mismatch; would PATCH state=1 (accountEnabled: intended False, observed True)
IDF0001003: pending, the ISC copy predates the change; re-run after the next aggregation
[dry-run] IDF0001004: verified; would PATCH state=3
IDF0001005: skipped, the intended state names nothing a re-read can check
[dry-run] IDF0001006: verified; would PATCH state=3
1 mismatch, 1 pending, 1 skipped, 3 verified

Run the same records a day later, and keep the results in out/reread.json (the client makes the out folder).
```
python clients/python/reread_verification.py --records-json tests/fixtures/reread/awaiting_records.json --observations-json tests/fixtures/reread/observations.json --now 2026-11-02T12:00:00Z --out-json out/reread.json
```
Expected: IDF0001003 is now mismatch; would PATCH state=1 (disabled: intended True, observed False), and the last line is 2 mismatch, 1 skipped, 3 verified. out/reread.json holds each result with its evidence hash.

Run the business rule’s tests.

node --test --test-name-pattern="redirected|verifier|exception approver|evidence alone|non-closing|SDIM" tests/servicenow/servicenow_scripts.test.js

Expected: tests 6, pass 6.

Delete the out folder.
```
rm -rf out
```

Check your work: for any waiting finding, you can say whether the client verifies it, reopens it, waits or skips it, and why.

Unit 6: Exercise: Lab 2 (your test instance)

Not timed. Not run by the authors.

Configure the business rule and its system properties, close a finding as a person and watch it land in Awaiting verification, confirm which user ServiceNow records for the verifier’s OAuth client, then close a finding with evidence from a Graph read of a disabled test user. Follow Chapter 05, Lab 2.

You need: the developer instance from Modules 1 and 2, the verifier user from Module 2’s Lab 2, and a test user in a test Entra tenant.
Back it out: step 5 deletes the test findings and their attachments, deactivates the business rule if you built it for the lab, and deletes the system properties.

Unit 7: Knowledge check

5 minutes

At noon on November 1, IDF0001003 is pending. Why?
1. The ISC copy of the account predates the change, so the client waits for the next aggregation.
2. The verifier account isn’t configured.
3. The intended state names nothing a re-read can check.
Under the business rule, which update can close a finding?
1. A person setting the state to Closed Complete.
2. Any update that carries new evidence.
3. An update from the verifier account that carries new evidence.
In offline mode, a waiting record’s subject has no saved read. What happens?
1. The record is verified, because nothing disagrees with the intended state.
2. It’s an error, because a missing read isn’t a match.
3. The record is reopened.
Why does the kit have no test for Gate 5?
1. Gate 5 is optional at FedRAMP Moderate.
2. Pass 1 doesn’t actuate, so Gate 5 is configuration of the products themselves.
3. The business rule covers it.

Check your answers

a. A read that predates the change waits; after the grace period it becomes a mismatch. See steps 2 and 3 of Chapter 05, Lab 1.
c. Evidence alone, or the verifier alone, isn’t enough. See step 1 of the guide’s Gate 6 and step 4 of Chapter 05, Lab 1.
b. See the offline mode in Chapter 05: what this chapter adds.
b. See the guide’s Validate (G5) step.

Unit 8: Summary

2 minutes

You learned where actuation runs on these products, how the business rule and the re-read client keep a ticket status from closing a finding, and how the client treats stale reads and empty intended states.

Evidence an ISSO keeps from this module: connector and spoke identities with their permissions, provisioning events, activation records and change records (Gate 5); the evidence attachment and hash on each closed record, the re-read result and time, and the verifier account’s audit trail (Gate 6 and Chapter 05). Before shipping, work through the Chapter 05 checklist.

Continue the path

Previous: Module 5 · Learning path · Next: Module 7, Evidence for the ISSO →