Deployment
Pick the painful domain. Connect what already exists. Ship Outcomes against it. Expand on your timeline. No transformation program. No 18-month implementation. No platform replacement.
What deployment looks like
XOPS sits above your existing stack. Nothing gets ripped out. No data migration. No SoR replacement. The first integration is read-only. The first runbook fires in dry-run. The first Outcome runs in production after your team signs off — not before.
What deployment is not
What deployment is
The four-step adoption motion
XOPS doesn’t ask you to rearchitect anything. The adoption motion is the same regardless of which domain you start with: pick the painful one, connect what already exists, ship Outcomes against it, expand on your timeline.
Step 01
Pick the domain with the highest pain or the cleanest savings. We recommend; you decide. Most customers start with Device Lifecycle — universal work, measurable savings, runbooks ready to fire.
Step 02
Read-only connectors to the SoRs your first domain depends on (typically 6–12). Nothing gets replaced. Nothing gets migrated. Write-back is enabled later, with explicit policy sign-off.
Step 03
Pre-built runbooks tuned to your policies. Dry-runs against staging before any production change. Your operators review and approve every Outcome before it goes live. Production by week 9.
Step 04
The first domain proves the math. The next is your call — based on where the next pain lives, not on a sales calendar. Same pattern. Same timeline. Same governance. Different surface area.
A typical first-domain rollout
Your milestones, against ours. Every phase ends with explicit sign-off — not a gate we control. The platform earns each step before it takes the next.
Days 1–30
Sign-off — ready to configure
Days 31–60
Sign-off — ready to ship
Days 61–90
Sign-off — ready to expand
Operational ownership
We own the platform and the runbooks. You own access, policy, change management, and pace. Every action is attributable; every escalation has an owner.
XOPS owns
You own
Integration motion
We connect to your systems the way your engineering team would connect their own services. Standard protocols. Standard auth. No proprietary agents on your endpoints. No data leaves your environment until you say so.
Phase A
First connectors come up in pure read mode. The Living Knowledge Graph starts reflecting operational state. No write-back to any SoR. You can pull the plug at any time and nothing changes in your stack.
Phase B
Runbooks fire against a staging slice or a low-risk subset of production. Every action logged, every diff visible. Your operators review before any write-back is enabled in scope.
Phase C
Write-back enabled with explicit policy sign-off. Initial scope is intentionally narrow — one runbook, one workflow, one slice. Expansion is gated on observed performance, not calendar.
Phase D
By end of week 9, the first domain’s Outcomes run end-to-end across the systems involved. Continuous monitoring. Continuous reconciliation. Continuous audit log.
Governance & rollback
Determinism without rigidity. The platform is governed by design, but your operators always have the override. The backstep saga lets you reverse any Outcome — coordinated, bounded, attributable.
Pause
An operator can pause any event source — workflow, agent, schedule, ticket queue — without taking the platform down.
Override
Any Outcome can be overridden mid-flight by an authorized operator. The override is logged with reason and reviewer.
Replay
Any Outcome can be replayed against new state, with parameter edits, before committing. Useful for hard-to-test exception paths.
Backstep
The backstep saga reverses any Outcome that shouldn’t have shipped — coordinated across the same systems, with the same governance, in reverse.
You can audit every action by source, by entity, by time. SOC 2, ISO 27001, and your trust-center expectations all met by design.
Less invasive than most ServiceNow upgrades. One domain first. The math you can take to the board comes from the data the deployment generates.
