Post-delivery governance
Pulse Sustainment Mode
A governed operational record for the years after delivery—preserving the as-built baseline, change authority, configuration history, compliance evidence, and procurement actions for the systems your organization must continue to own and defend.
Works with Jira and ServiceNow — not instead of them
PSM is the governed sustainment record: as-built baselines, change authority, board votes, attestations, compliance events, and the cryptographic audit trail. Your teams keep working in ServiceNow or Jira for day-to-day tickets — approved Change Requests mirror there so leadership sees the whole picture without AIM surrendering the decision thread.
Jira, ServiceNow, SysML v2, and Cameo adapters are configured in your organization's Integration Hub. Governance stays in AIM; execution stays in the tools your teams already run. See Mission Control interoperability →
Why Pulse Sustainment Mode exists
Most modernization programs track the build. Almost none track what happens after.
The system is delivered, the implementation team rolls off, the project closes — and from that day forward the customer is on their own to keep it running, patch it, sustain its staffing, defend it in audits, and explain it to the next leadership team. By Year 2 most organizations have lost the thread on what was actually delivered, who signed off, why a specific decision was made, and what trade-offs were on the table at the time.
Pulse Sustainment Mode is the layer that prevents that. The day your implementation closes, PSM freezes the original Pulse as a permanent as-built baselineand starts the operational record — change requests, board decisions, configuration changes, compliance events, and procurement actions — all attributable, all timestamped, all linked to the original assessment context that produced the system.
Governed by organization entitlements
PSM is available when Pulse Sustainment is enabled in the organization agreement. Capacity, integrations, support, and future autonomous-operations capabilities are governed by the organization's contract and explicit entitlement profile.
What PSM tracks
Six lifecycle event types, captured with attribution and timestamp, tied back to the original assessment.
As-Built Baseline
A permanent, immutable snapshot of the system the day sustainment activates. The original Pulse becomes the canonical "what was actually delivered" — read-only, signed-off, and used as the comparison anchor for every later change.
Change Requests
Anyone with appropriate access can file a CR proposing a change. Each CR moves through categorization, board review, voting, implementation, and attestation — with full vote records and rationale captured at every step.
Change Control Board
A configurable board of named voters per change category — engineering, security, finance, compliance, etc. The org decides who is on the board and what categories they vote on. Voting outcomes are recorded with each voter's comment.
Configuration Changes
Routine operational changes — version upgrades, scaling adjustments, dependency updates — captured against the as-built baseline so you always know how far the running system has drifted from what was originally delivered.
Compliance Events
Audit findings, framework re-certifications, policy waivers, control attestations — anything that touches the system's compliance posture, recorded with the framework, the finding, and the disposition.
Procurement Actions
License renewals, support contract extensions, hardware refreshes, vendor changes. The system has a financial life of its own after delivery — PSM keeps that record alongside the technical one.
How it works
PSM follows a simple lifecycle. Every step is auditable.
Activate from a completed Pulse — or adopt an existing system
When a Project Pulse implementation reaches its final attested milestone, an Owner or Admin activates Pulse Sustainment Mode for that project. The original Pulse is frozen as the as-built baseline and the sustainment record begins. Already-running systems that were never modernized through AIM can also be onboarded directly through a guided adoption flow that captures their current state as the baseline.
Designate a Lead and a Backup
Every PSM has a named Designated Lead and Backup Lead — the people accountable for sustainment milestones, board coordination, and the operational record. Leads must be Owners, Admins, or Engineers. This separation of duties is what makes the audit trail defensible.
Configure the Change Control Board
The org chooses who votes on which categories. Default categories are pre-loaded based on the organization's sector — federal agencies see different defaults than healthcare systems or commercial enterprises. Categories and voters are configurable at any time.
File, vote, implement, attest
Anyone with access can file a Change Request. The CR is categorized, the assigned board votes, implementation proceeds if approved, and the Lead attests when the change is delivered. Every state transition is timestamped and attributable.
Publish the operational record (optional)
Owners and Admins can publish a sanitized public dashboard for stakeholders — councils, sponsors, auditors. The published view shows operational status without exposing internal user names, emails, or sensitive context. Embeddable as an iframe on external sites.
Org-wide audit feed
Owners and Admins see a single org-wide audit feed of every PSM event across every system: lead changes, CR votes, attestations, configuration changes, compliance events. One view, the whole portfolio, fully searchable.
Who can do what
PSM uses your existing AIM org roles. No separate accounts to manage.
| Action | Owner | Admin | Engineer | Reviewer | Program Analyst | Viewer |
|---|---|---|---|---|---|---|
| Activate PSM / adopt a system | ✓ | ✓ | — | — | — | — |
| Be named Designated or Backup Lead | ✓ | ✓ | ✓ | — | — | — |
| Attest sustainment milestones (Lead-only for Engineers) | ✓ | ✓ | ✓ | — | — | — |
| Configure CCB membership and categories | ✓ | ✓ | — | — | — | — |
| File a Change Request | ✓ | ✓ | ✓ | ✓ | ✓ | — |
| Vote on CRs (when on the board) | ✓ | ✓ | ✓ | ✓ | ✓ | — |
| Attest CR closeout | ✓ | ✓ | ✓ | ✓ | — | — |
| Publish public PSM dashboard | ✓ | ✓ | — | — | — | — |
| View org-wide PSM audit feed | ✓ | ✓ | — | — | — | — |
| View PSM detail and history | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
Reviewers attest CR closeouts (sign-off that a delivered change matches what was approved) but do not attest sustainment milestones. That responsibility is reserved for the named Lead — preserving separation of duties.
ITSM Integration — ServiceNow & Jira
PSM connects to your existing IT service management platform so Change Requests filed in AIM automatically appear in the tools your teams already use.
Supported platforms
- •ServiceNow — Change Requests sync to ServiceNow incidents or change records
- •Jira Cloud — Change Requests sync to Jira issues in your selected project
How it works
- •When a CR is created or advances in AIM, the integration automatically creates or updates the corresponding ticket
- •Status changes in ServiceNow or Jira mirror back to AIM so both systems stay in sync
- •State mappings are fully configurable — you choose which AIM CR state maps to which external status
Important: AIM remains the system of record
The ITSM integration is additive, not a replacement. CCB vote records, attestations, compliance events, and the cryptographic audit trail all live in AIM regardless of whether an external system is connected. Your teams keep using ServiceNow or Jira exactly as they do today — PSM connects the formal governance layer to their work surface.
The integration is specific to PSM Change Requests. It does not sync Project Pulse epics or implementation tasks. Project Pulse operates at a strategic delivery altitude — your engineers keep using their existing tools for sprint planning and ticket management during the implementation phase.
How to configure
- Go to Integrations in the workspace (Owner or Admin role required)
- Click + New integration, select your provider (ServiceNow or Jira Cloud), and enter your instance credentials
- AIM validates the credentials against your live instance before saving anything
- Copy the webhook URL and signing secret displayed after creation — configure these in your ServiceNow or Jira instance to enable inbound status updates
- Configure state mappings to match your workflow — for example, map AIM's voting state to Jira's In Review status
- Bind the integration to one or more PSMs from the PSM settings panel
Operations record
For a system already in sustainment, an Owner or Admin can read one ServiceNow business application, service, or application and compare it with the last reading this organization accepted.
What people see
- •Overview shows whether the operations record matches the last accepted reading, or how many differences exist.
- •Configuration lists each difference as before and after. A person files a change request. A reviewer still confirms the category before anyone votes.
- •The reading updates when someone refreshes it, or on AIM's daily check. It is not a live feed from ServiceNow.
- •If ticket sync is already connected, filing queues a Jira or ServiceNow ticket. If it is not, the request stays in AIM, and an Owner or Admin can connect that same ServiceNow account and send the ticket.
What this does not do
- •AIM does not become the configuration database, and it does not change records in ServiceNow.
- •Jira can receive the change-request ticket. Jira is not a source for the operations record.
- •One sustainment record sends tickets to one system, Jira or ServiceNow.
- •Project Pulse work is not included. The public sustainment page does not show the operations record.
- •A new reading becomes the comparison only when an Owner or Admin accepts it, or checks that choice while freezing a baseline.
Common questions
Does Pulse Sustainment Mode cost extra?
PSM access is governed by the organization agreement. AIM does not expose per-PSM fees or per-change-request charges inside the product.
What happens to the original Project Pulse when sustainment activates?
The implementation Pulse is frozen and becomes the canonical as-built baseline that PSM tracks against. It remains viewable in read-only mode forever — it does not disappear, it becomes the source of truth for what was originally delivered. You can always click back to it from any PSM record.
Can we activate PSM for systems we never modernized through AIM?
Yes. The adoption flow lets an Owner or Admin onboard an existing operational system into PSM directly. You attest the current state — technology stack, vendor relationships, compliance scope — and that becomes the as-built baseline going forward. Optionally you can retroactively link an older AIM assessment to the adopted PSM if one exists.
Who is on the Change Control Board by default?
PSM ships with a set of default change categories tuned to your organization sector. Each category has a recommended voter slate (e.g., engineering, security, finance, compliance) but the actual voters are always chosen by your Owners and Admins. You can add categories, remove them, or change voter membership at any time.
What is the public dashboard for?
It's an optional, sanitized, read-only view of a PSM's operational status that you can share with external stakeholders — council members, audit sponsors, executive leadership outside the IT team. It hides internal user names, emails, and sensitive context. You decide what gets published, and you can unpublish at any time.
Can a Reviewer attest sustainment milestones?
No. Sustainment milestone attestation is reserved for the named Designated or Backup Lead (who must be an Owner, Admin, or Engineer). Reviewers can vote on CRs when they are on the board, and they can attest the closeout of an individual change — but the milestone sign-off itself stays with the Lead. This is intentional separation of duties.
Is the audit trail tamper-proof?
Yes. PSM events are written to an append-only audit log. The database physically rejects modifications to historical records, and every attestation is cryptographically signed. The audit feed is the same evidentiary standard AIM uses for assessment-level provenance — defensible in front of regulators, auditors, and oversight bodies.
Can PSM connect to ServiceNow or Jira?
Yes, when ticket sync is connected on that sustainment record. Owners and Admins add ServiceNow or Jira Cloud under Integrations, then bind that connection in the sustainment record's Settings. Filed and later change-request updates are queued to that one ticket system, and status changes can mirror back. If ticket sync is not connected, the request stays in AIM.
If PSM connects to Jira or ServiceNow, which is the system of record?
AIM is always the system of record for governance. The CCB vote records, attestations, compliance events, and the cryptographic audit trail all live in AIM regardless of whether an external system is connected. ServiceNow and Jira receive a mirror of the Change Request for team visibility — they do not replace the governance record.
Can AIM read our configuration database?
For a system in Pulse Sustainment, an Owner or Admin can link one ServiceNow business application, service, or application. AIM compares later readings with the last reading the organization accepted and can turn a difference into a change request. AIM does not replace that configuration database, does not edit it, and does not read Jira as a configuration source. Hardware inventories and other record types are not imported as AIM systems.
Does the ITSM integration work with Project Pulse too?
No — the ITSM integration is specific to PSM Change Requests. It does not sync Project Pulse epics, phases, or implementation tasks. Project Pulse is designed as a strategic delivery heartbeat; your teams keep using Jira or ServiceNow for day-to-day implementation work during the modernization phase. The ITSM connection activates after delivery when PSM takes over the operational governance layer.
Related reading
Project Pulse
The implementation-tracking layer that PSM activates from.
Teams & Access
Detailed role permissions for PSM, CCB membership, and lead designation.
Decision Provenance
How AIM's audit and attestation system makes the sustainment record defensible.
AIM Mission Control
Scout observation compares live gateway evidence with the documented AIM and Pulse Sustainment baseline.
Ready to start the sustainment record?
Activate PSM from any completed Project Pulse, or adopt an existing system into the sustainment lifecycle.