XOPS

Deployment

How adoption
actually works.

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

Less invasive than
most ServiceNow upgrades.

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

No rip-and-replace.

  • No SoR replacement. Workday stays. ServiceNow stays. Okta stays. The systems you already run keep running.
  • No data migration. The graph reads from your systems; it doesn’t replace their state of record.
  • No 18-month implementation. Production by week 9 against the first domain, with the heavy lifting on our side, not yours.
  • No certification programs. Operators learn from the runbooks themselves, not 200-slide training tracks.

What deployment is

Connect, configure, run.

  • Connectors to your first domain’s SoRs. Typically 6–12 systems. Read-only first; write-back enabled with explicit sign-off.
  • Pre-built runbooks loaded. Tuned to your policies, not configured from scratch. The work is universal; the parameters are yours.
  • Dry-runs against staging. Your operators review every action and approve every Outcome before write-back goes live.
  • First Outcome in production by week 9. Measured against the baseline you set in week 1. Math you can take to the board.

The four-step adoption motion

Same pattern, regardless of where you start.
One domain at a time.

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 1

Start with one operational domain

Start with the use case that solves your biggest pain on day one — Device, Software, AI, or another domain. We recommend; you decide. Whichever you choose, the work is repeatable, the impact is measurable, and the runbooks are ready to fire.

Step 2

Connect existing systems

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 3

Deploy initial Outcomes

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 4

Expand incrementally

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.

The first domain should pay for itself

Start with the use case that solves your biggest pain on day one — Device, Software, or AI. Wherever you begin, the first domain proves the motion and the math. At one Fortune 500 technology enterprise, signal-driven device refresh is delivering $4.5M+ in annual savings while extending average device life 1–2 years.

See the Smart Refresh case study

$4.5M+

Saved per year

+1–2 yrs

Avg device life

Software Lifecycle · modeled potential

A typical 10,000-seat organization models $1–5M in potential year-one license recovery — a projection based on the Software Position, not yet a realized customer result.

A typical first-domain rollout

Day 1 to first production Outcome.
By week nine.

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.

Weeks 1–4

Discover & connect

  • · Walk the operational reality with your team. Identify the painful domain.
  • · Set the baseline metrics that will measure success in week 9.
  • · Sign the data-handling addendum. Provision SoR access (read-only).
  • · Connectors come online. The graph starts reflecting your operational state.

Sign-off: ready to configure

Weeks 5–8

Configure & rehearse

  • · Pre-built runbooks tuned to your policies, side-by-side with your operators.
  • · Dry-runs against staging. Every action reviewed. Every exception documented.
  • · Governance, audit, and rollback rehearsed end-to-end.
  • · Write-back enabled with explicit policy approval, scoped slice first.

Sign-off: ready to ship

Week 9+

Live & measure

  • · First Outcome runs in production against the agreed scope.
  • · Measured against your week-1 baseline. Numbers you can take to the board.
  • · Additional Outcomes layered as your team gets comfortable.
  • · Quarterly review: what to expand to next, on your timeline.

Sign-off: ready to expand

Operational ownership

Joint ownership.
No ambiguity.

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

  • · Connector implementation and maintenance. Across every system in the first domain’s scope.
  • · Runbook configuration, tuning, and updates. The work is universal; we tune to your parameters.
  • · Platform uptime, security, and audit log. SOC 2, ISO 27001, ISO 42001, your trust center expectations.
  • · Pre-built Outcome library and pattern releases. New runbooks ship as we learn from the customer cohort.
  • · Office of the Field CTO availability. Operators on our team you can borrow when you hit a hard problem.

You own

  • · SoR access and credentials. Provisioned through your IGA. Read-only first; write-back later.
  • · Policy approvals and sign-off on each Outcome. Nothing fires in production without your operator signing.
  • · Internal change management. Operator comms, runbook reviews, organizational readiness.
  • · First-domain selection. We recommend based on the pain we see; you decide based on the pain you live.
  • · Pace of expansion. The next domain is your call, not a sales calendar.

Integration motion

Read first.
Write second. With sign-off.

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 production write-back occurs until you explicitly approve it.

Phase A

Read-only connectors

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

Dry-run write-back

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

Scoped production

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

Full first-domain

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

Pause anything.
Roll back anything. Audit everything.

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

Stop any source

An operator can pause any event source (workflow, agent, schedule, ticket queue) without taking the platform down.

Override

Manual decision

Any Outcome can be overridden mid-flight by an authorized operator. The override is logged with reason and reviewer.

Replay

Re-run with edits

Any Outcome can be replayed against new state, with parameter edits, before committing. Useful for hard-to-test exception paths.

Backstep

Reverse the saga

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, ISO 42001, and your trust-center expectations all met by design.

First Outcome in production. By week nine.

Less invasive than most ServiceNow upgrades. One domain first. The math you can take to the board comes from the data the deployment generates.

Request demo Back to the platform