Service Definitions & Sample SOWs
Build Readiness · Launchpad · Governed Operations
Prepared for: Internal / partner review — Airiam ATD (AI Trust Services) · Status: Draft v1.0
Owner: Greg (BD / GTM) · Approver: Kuk (CEO) · Delivery: Pedro / Daniel (ATD)
How to read this document
These are the three Build Safely offerings, defined so a prospect, a delivery lead, and a CEO can all read from the same page. For each offering you get four things: what the service actually is, the level of effort to deliver it, what we need from the customer, and a sample Statement of Work ready to be scoped into Airiam’s corporate template.
Everything here is base case. Effort ranges are expected values for a typical SMB environment, not commitments — real scope is set per engagement. All dollar figures are placeholders and must be populated against the current rate card before anything goes to a prospect.
The through-line: Build Readiness is the one-time wedge. Launchpad and Governed Operations are the recurring managed services it converts into. We never build the customer’s agent or app — we run the safe path around whatever they build. Build Readiness sets things up safely; Launchpad adds build-time release gates and monitoring; the live runtime governance (SDK, engine, gateway, RAIVS) exists only in Governed Operations (Tier 2).
Which offering leads, by buyer
Same three offerings, sequenced to where the buyer’s risk actually sits. Lead with the entry point on the left; the recurring tiers follow as the relationship matures.
| Buyer situation | Lead with | Why |
|---|---|---|
| Using AI but unsure where the risk is | Build Readiness | They need visibility before anything else. |
| Building apps, automations, or agents quickly | Build Readiness → Launchpad | They need a safe, monitored release path. |
| Running agents that take real actions in live systems | Governed Operations | Runtime action risk is the actual exposure. |
| Answers to a regulator, client, insurer, or audit (healthcare, finance, legal, contractors) | Launchpad or Governed Operations + Regulated overlay | They must prove control, not just have it. See the overlay at the end of this document. |
A note on the regulated column. Compliance-driven buyers do not get a different product — they get the same three offerings plus a thin, separately-scoped Regulated / CMMC overlay that adds boundary scoping, a control-family mapping, evidence-export packaging, and external-provider review. One product, one overlay. It is defined in the appendix.
OFFERING 1 · TIER 0 · ONE-TIME
Build Readiness
A fixed-scope professional-services engagement that answers one question honestly: what has your team already built with AI, and what needs fixing first? It produces a clear picture of the current state and a safe starting point to build from. It does not stand up any live runtime governance — that comes with Governed Operations.
What the service looks like
A short, defined engagement run mostly by Airiam with light customer involvement. It has four moving parts:
- A discovery sweep. We inventory what the team has actually shipped across their build surface — Copilot/M365, Claude, ChatGPT, and any vibe-coded or scripted apps — plus the repos, keys, and data those touch. Read-only; we change nothing in production.
- A plain-English risk report. Exposed keys and secrets, data pointed at the wrong place, apps and agents with no owner, and anything running that nobody is watching — ranked by what to fix first.
- An approved-tools list and a simple AI use policy. A short, usable statement of which tools are sanctioned and the ground rules for building with them — sized for an SMB, not a 40-page enterprise policy.
- A secure starting setup. An optional “Readiness Setup” add-on: a clean, safe baseline configuration to build from, so the next thing they ship starts on solid ground.
Boundary (state it plainly): Build Readiness is a point-in-time assessment and setup. It does not include the Airiam SDK, the governance engine, the Action Gateway, or the RAIVS runtime audit chain — those are runtime capabilities that exist only in Governed Operations (Tier 2). Launchpad adds build-time gates and monitoring, but not runtime action control. Selling Tier 0 as if it delivers live governance is the exact overstatement we don’t make.
Responsibility. Airiam provides governance and evidence. The customer remains responsible for business approvals, legal determinations, compliance certification, and final risk acceptance.
Level of effort (Airiam — base case)
Typical small-business environment. Larger or multi-entity environments scale up; a single-app team scales down.
| Phase | What happens | Base-case effort |
|---|---|---|
| Kickoff & access | Scope confirmation, sponsor intro, read-only access provisioning | 0.5 day |
| Discovery sweep | Tooling inventory across build surface + 2–3 short interviews | 3–5 days |
| Analysis & report | Risk ranking, drafting the plain-English report | 2–3 days |
| Policy & tools list | Approved-tools list + short AI use policy | 1–2 days |
| Readiness Setup (opt.) | Secure baseline configuration to build from | 2–4 days |
| Readout | Findings walkthrough + fix-first roadmap | 0.5 day |
| Total | Elapsed ~2–4 weeks; roughly 40–80 hours of Airiam effort | 1–2 wk core |
What is required from the customer
- A named sponsor and a single point of contact for the duration.
- Read-only access to the relevant environments: M365 tenant (admin or delegated read), source repositories, and cloud consoles where apps or agents run.
- A self-reported starting list of AI tools in use — a rough list is fine; completing it is part of what we do.
- Availability for two to three short interviews (30–45 minutes each) with the people who build.
- No production changes and no downtime are required from the customer.
Sample Statement of Work — Build Readiness
SAMPLE STATEMENT OF WORK
AI Build Readiness Assessment
Reference: SOW-BUILDREADY-2026-0XX Type: One-time professional services (fixed fee)
1. Background & purpose
Customer’s team has begun building with AI tools and applications and lacks a consolidated view of what is running, where the exposure is, and what to standardize. This engagement establishes that baseline and a safe starting point.
2. Scope of services — in scope
- Read-only discovery sweep of the AI/app build surface (Copilot/M365, Claude, ChatGPT, vibe-coded and scripted apps) and the repositories, credentials, and data sources they touch.
- Plain-English risk report with findings ranked by remediation priority.
- Approved-tools list and a concise AI use policy sized for the organization.
- Optional Readiness Setup: a secure baseline configuration to build from (see fees).
- Findings readout and a fix-first roadmap.
3. Out of scope
- Remediation or implementation of fixes (available as a follow-on engagement).
- Any live/runtime governance — SDK module, governance engine, Action Gateway, or RAIVS audit chain (these runtime capabilities are delivered under Governed Operations; Launchpad adds build-time gates and monitoring only).
- Building, rebuilding, or modifying the customer’s agents or applications.
- Penetration testing or formal compliance certification.
4. Deliverables
| ID | Deliverable |
|---|---|
| D1 | AI asset & tooling inventory |
| D2 | Prioritized plain-English risk report |
| D3 | Approved-tools list + AI use policy |
| D4 | (Optional) Secure baseline setup |
| D5 | Readout deck + fix-first roadmap |
5. Customer responsibilities
- Named sponsor and single point of contact.
- Read-only access to M365 tenant, repositories, and cloud consoles.
- Initial self-reported list of AI tools in use.
- Participation in 2–3 discovery interviews.
6. Assumptions
- Single business entity / one primary M365 tenant. Additional entities are a change order.
- Access is provisioned within 5 business days of kickoff.
- Findings reflect the environment as observed during the engagement window.
7. Timeline (base case)
| Phase | When |
|---|---|
| Kickoff & access | Week 1 |
| Discovery & interviews | Weeks 1–2 |
| Analysis & drafting | Week 2–3 |
| (Optional) Readiness Setup | Week 3 |
| Readout | Week 3–4 |
8. Fees & payment
| Item | Amount / terms |
|---|---|
| Build Readiness Assessment | Fixed fee — $[TBD] (populate from rate card) |
| Readiness Setup (optional add-on) | Fixed fee — $[TBD] |
| Payment terms | [e.g. 50% on kickoff, 50% on readout] — Net [15/30] |
All figures are placeholders — populate from the current rate card before delivery. Modeled figures are base-case expected values, not forecasts.
9. Acceptance
Deliverables are deemed accepted on delivery of the readout and roadmap, unless Customer provides written exceptions within 5 business days.
Conversion note (internal): This engagement is the wedge. The risk report and fix-first roadmap create the natural path into Launchpad (ongoing protection of what they build) and, for regulated buyers, Governed Operations.
Agreed and accepted
| Airiam MDT LLC — name, title, date | Customer — name, title, date |
|---|
OFFERING 2 · TIER 1 · MONTHLY
Launchpad
The recurring managed layer. It keeps what the team builds from quietly breaking or exposing the business, by gating every release before it reaches production and monitoring what’s live. This is build-time protection and observability — it is the on-ramp tier, and it does not yet govern what an agent does at runtime.
What the service looks like
A managed service Airiam operates on the customer’s behalf, standing up once and then run monthly:
- Safe-by-default templates. Vetted starting patterns to build from, so new work begins on a known-good baseline instead of a blank canvas.
- Release gates in their pipeline. Before any new version reaches production, Airiam’s gates scan for hardcoded secrets and keys, insecure code, bad or vulnerable dependencies, and unsafe configuration. A build that fails is stopped before it goes live.
- Monitoring and alerts. Continuous watch on what’s running, with alerts that surface problems before customers hit them.
- A safe deploy path. A controlled route from a tested build to production — the same tested artifact is what ships.
Boundary: Launchpad governs the ship (build-time gates) and watches the running app. It does not sit in the runtime path of an agent’s actions — there is no Action Gateway verdict on “send this email” or “pay this invoice” at this tier. Runtime action control is Governed Operations. Launchpad is the prerequisite it builds on.
Responsibility. Airiam provides governance and evidence. The customer remains responsible for business approvals, legal determinations, compliance certification, and final risk acceptance.
Level of effort (Airiam — base case)
Split into one-time onboarding and steady-state monthly operations.
| Phase | What happens | Base-case effort |
|---|---|---|
| Onboarding | Wire release gates into CI/CD, provision templates, configure monitoring & alert routing | 1–3 weeks setup |
| Validation | Run gates against current builds, tune thresholds, confirm safe deploy path | 3–5 days |
| Steady state | Gate maintenance, alert triage, monitoring, monthly review | Ongoing / managed |
| Cadence | Monthly service review; gate & template updates as tools evolve | Monthly |
What is required from the customer
- A pipeline / CI-CD to integrate gates into, or willingness to adopt Airiam’s recommended deploy path.
- Repository and deploy-hook access sufficient to run gates and promote builds.
- A named owner for each app or agent under management.
- A completed Build Readiness (or an equivalent baseline) is the recommended prerequisite.
- Agreement that gates are not bypassed — a failing build does not ship.
Sample Statement of Work — Launchpad
SAMPLE STATEMENT OF WORK
Launchpad Managed Service
Reference: SOW-LAUNCHPAD-2026-0XX Type: Recurring managed service (monthly)
1. Background & purpose
Customer’s team continues to build and ship AI-assisted applications and agents and needs ongoing assurance that new versions do not introduce exposed secrets, insecure dependencies, or unmonitored failures. Airiam operates the build-time safety and monitoring so the team can keep moving.
2. Scope of services — in scope
- Provisioning of safe-by-default build templates.
- Integration and operation of release gates (secrets, code, dependencies, configuration) in Customer’s pipeline.
- Continuous monitoring and alerting on managed applications/agents.
- Operation of a controlled deploy path from tested build to production.
- Monthly service review and ongoing gate/template maintenance.
3. Out of scope
- Runtime action governance — SDK module, governance engine, Action Gateway, human-approval workflows, and RAIVS (delivered under Governed Operations).
- Building or modifying the customer’s applications or agents.
- Remediation of pre-existing issues surfaced at onboarding (scoped separately or via Build Readiness).
- 24/7 SOC / incident response beyond agreed alerting (available as an add-on).
4. Deliverables
| ID | Deliverable |
|---|---|
| D1 | Configured release gates in pipeline |
| D2 | Safe-by-default template set |
| D3 | Monitoring & alerting, live |
| D4 | Controlled deploy path |
| D5 | Monthly service review report |
5. Customer responsibilities
- Pipeline/CI access and deploy hooks.
- Named owner per managed app or agent.
- Adherence to the gated deploy path (no bypass of failing gates).
- Timely response to alerts requiring customer-side action.
6. Assumptions
- Build Readiness (or equivalent baseline) completed prior to or at onboarding.
- Managed scope is [N] applications/agents; additional units priced per the rate card.
- Customer maintains its own source control and cloud accounts.
7. Timeline (base case)
| Phase | When |
|---|---|
| Onboarding & gate integration | Weeks 1–3 |
| Validation & tuning | Week 3–4 |
| Service commencement | Month 1 |
| Recurring service reviews | Monthly |
8. Fees & payment
| Item | Amount / terms |
|---|---|
| Onboarding (one-time) | Fixed fee — $[TBD] |
| Monthly service | From $[~a few hundred] / mo per app, agent, or seat (base case) — populate from rate card |
| Billing unit | [per app / per agent / per seat] |
| Payment terms | Monthly in advance — Net [15/30] |
All figures are placeholders — populate from the current rate card before delivery. Modeled figures are base-case expected values, not forecasts.
9. Acceptance
Service is deemed live upon successful validation of gates and monitoring against Customer’s current builds; ongoing service is measured against the agreed monthly review.
10. Term
Initial term [12 months], auto-renewing monthly thereafter unless cancelled with [30] days’ notice.
Conversion note (internal): Launchpad is the high-volume on-ramp and the prerequisite for Governed Operations. Regulated or contractually-bound customers on Launchpad are the cleanest upsell path to Tier 2.
Agreed and accepted
| Airiam MDT LLC — name, title, date | Customer — name, title, date |
|---|
OFFERING 3 · TIER 2 · MONTHLY
Governed Operations
The full runtime control plane. Everything in Launchpad, plus live governance of what an agent actually does — every consequential action routed through a policy verdict, high-risk actions held for human approval, and every decision sealed in a tamper-evident record you can hand an auditor. This is where the differentiation lives, for buyers who answer to a regulator, client, or insurer.
What the service looks like
Everything in Launchpad, operated by Airiam, plus the runtime layer:
- The Airiam SDK module. A lightweight module the customer’s agent calls before it acts — regardless of where the agent was built (Copilot, Claude, ChatGPT, vibe-coded).
- The governance engine. Scores the risk of each action and checks it against policy, using the Sentinel AI classifier or fixed deterministic rules — the customer’s choice.
- The Action Gateway. Returns one of four verdicts on every consequential action: allow, ask (confirm), approve (route to a human), or block. Low-risk work stays fast; consequential work stops at the checkpoint.
- Human approval workflows with separation of duties. The person who builds the agent cannot approve its high-risk actions or its own promotion to production. Approval routes to an authorized human.
- A controlled test-to-live path with rollback. Managed promotion with the ability to roll back safely.
- The RAIVS audit chain. Airiam’s Risk-Adaptive AI Verification System — a forward-secure, tamper-evident chain where every gated decision and action is sealed. This is the proof handed to an auditor, client, or insurer.
- Integration to systems of record via a native API connector Airiam configures, or the customer’s own MCP server. The gateway governs the action either way.
Boundary: We still never build the customer’s agent. Governed Operations governs what the agent ships and what it does; it does not author the agent’s logic. And it builds on Launchpad — it is not sold as a standalone without the build-time gates and monitoring underneath it.
Responsibility. Airiam provides governance and evidence. The customer remains responsible for business approvals, legal determinations, compliance certification, and final risk acceptance.
Level of effort (Airiam — base case)
The heaviest onboarding of the three, driven by the number of systems and the complexity of the policy. Larger environments and more regulated contexts scale up.
| Phase | What happens | Base-case effort |
|---|---|---|
| Policy workshops | Define consequential actions, thresholds, data classes, approver roles | 1 week |
| SDK & engine setup | Deploy SDK module into runtime, configure governance engine + rules/classifier | 1–2 weeks |
| Gateway & approvals | Configure four-verdict policy, approval routing, separation of duties | 1 week |
| Integrations | Connect systems of record via native API or customer MCP server | 1–2 weeks |
| RAIVS & validation | Stand up audit chain, run end-to-end scenarios, confirm seals | 3–5 days |
| Steady state | Operate control plane, triage approvals infra, produce evidence on demand | Ongoing / managed |
| Onboarding total | Elapsed ~3–6 weeks base case; quarterly policy review thereafter | 3–6 wk |
What is required from the customer
- Named approvers with real authority, distinct from the people who build — separation of duties is a hard requirement, not a preference.
- An access pattern to systems of record: either credentials for the native API connector Airiam configures, or a functioning MCP server the customer already runs.
- Policy input: which actions are consequential, the thresholds that matter (e.g. dollar amounts), and data-sensitivity classes (e.g. PHI, PII).
- Launchpad in place — Governed Operations builds on it.
- The compliance or contractual context: what the customer must prove, and to whom.
- A runtime integration point in each agent/app where the SDK module is called.
Sample Statement of Work — Governed Operations
SAMPLE STATEMENT OF WORK
Governed Operations Managed Service
Reference: SOW-GOVOPS-2026-0XX Type: Recurring managed service (monthly) + onboarding
1. Background & purpose
Customer operates in a regulated or contractually-bound context (e.g. healthcare, finance, legal, contracting) and must ensure that AI agents take only approved actions, that high-risk actions receive human approval, and that every decision is provable to an auditor, client, or insurer. Airiam operates the runtime governance control plane on Customer’s behalf.
2. Scope of services — in scope
- Everything under Launchpad: templates, release gates, monitoring, safe deploy path.
- Deployment and operation of the Airiam SDK module in Customer’s runtime.
- Governance engine: risk scoring and policy verification (Sentinel AI classifier or deterministic rules).
- Action Gateway with four-verdict enforcement (allow / ask / approve / block).
- Human-approval workflows enforcing separation of duties.
- Controlled test-to-live promotion with rollback.
- RAIVS forward-secure, tamper-evident audit chain and evidence export.
- Integration to systems of record via native API connector or Customer MCP server.
3. Out of scope
- Authoring, building, or modifying Customer’s agents or applications.
- Legal determination of regulatory compliance (Airiam provides evidence and controls; Customer’s counsel/auditor makes compliance determinations).
- Approval decisions themselves (made by Customer’s authorized approvers).
- Systems-of-record licensing or hosting.
4. Deliverables
| ID | Deliverable |
|---|---|
| D1 | Deployed SDK module in runtime |
| D2 | Configured governance engine + policy |
| D3 | Action Gateway with four-verdict policy |
| D4 | Approval workflows (separation of duties) |
| D5 | System-of-record integrations |
| D6 | Live RAIVS audit chain + evidence export |
| D7 | Monthly service review + quarterly policy review |
5. Customer responsibilities
- Named approvers with authority, distinct from builders.
- Access to systems of record (native API credentials or MCP server).
- Policy input: consequential actions, thresholds, data classes.
- Launchpad in place.
- Runtime integration point for the SDK in each managed agent/app.
- Timely approval decisions on routed actions.
6. Assumptions
- Launchpad is active for the same scope prior to or concurrent with onboarding.
- Managed scope is [N] agents/apps and [M] systems of record; additions priced per rate card.
- Policy definitions are provided by Customer during the policy workshops.
- Customer’s systems of record expose a supported API or MCP interface.
7. Timeline (base case)
| Phase | When |
|---|---|
| Policy workshops | Week 1 |
| SDK, engine & gateway setup | Weeks 2–4 |
| Integrations | Weeks 3–5 |
| RAIVS & end-to-end validation | Week 5–6 |
| Service commencement | Month 2 |
| Quarterly policy review | Quarterly |
8. Fees & payment
| Item | Amount / terms |
|---|---|
| Onboarding (one-time) | Fixed fee — $[TBD] (scales with # systems/policy complexity) |
| Monthly service | Four-figure / mo (base case), scoped to environment — populate from rate card |
| Billing basis | [per environment / per agent + per system of record] |
| Payment terms | Monthly in advance — Net [15/30] |
All figures are placeholders — populate from the current rate card before delivery. Modeled figures are base-case expected values, not forecasts.
9. Acceptance
Service is deemed live upon successful end-to-end validation: a consequential action correctly routed through each of the four verdicts and sealed in RAIVS. Ongoing service measured against monthly/quarterly reviews.
10. Term
Initial term [12 months], auto-renewing monthly thereafter unless cancelled with [30/60] days’ notice.
Conversion note (internal): This is the retention and margin tier. The RAIVS evidence chain is the switching cost — once a customer is handing auditors Airiam-sealed proof, they don’t leave.
Agreed and accepted
| Airiam MDT LLC — name, title, date | Customer — name, title, date |
|---|
APPENDIX · ADD-ON · ATTACHES TO ANY TIER · SEPARATELY SCOPED
Regulated / CMMC Overlay
Compliance-driven buyers do not get a different product. They get the same three offerings plus this thin overlay, scoped and priced separately, that turns the work into assessment-ready evidence. One product, one overlay — not a separate SKU per tier per framework. The overlay is where CMMC Level 2, NIST SP 800-171, and ISO 42001 language lives, so the core definitions stay clean for the general SMB market.
What the overlay adds
- CUI / sensitive-data boundary scoping. Identify which systems, repos, pipelines, AI tools, and integrations process, store, transmit, or protect regulated data — so every control is anchored to the boundary, not applied blindly across the business.
- A control-family mapping. Connect each Airiam governance capability to the NIST SP 800-171 families it supports (see table), so the customer can show an assessor how the work maps to their control implementation.
- Evidence-export packaging. Package approvals, gate results, deployment records, artifact hashes, action verdicts, and exception records into an export a customer can hand to an assessor, auditor, client, or insurer.
- External-provider review. Identify the MSPs, MSSPs, cloud providers, SaaS platforms, and AI vendors that touch in-scope assets — since external service providers are their own line of inquiry in an assessment.
- Risk-based logging discipline. Retain enough to show who acted, which tool, for what purpose, at what data classification, with what approval and disposition — without retaining the sensitive payload itself unless the logging platform is approved for that classification. Logging CUI or PHI into an unapproved store is itself a finding.
Airiam capability → NIST SP 800-171 family
A support map, not a compliance guarantee. It shows how the governance work lines up with the control families an assessor looks at.
| Airiam governance capability | NIST SP 800-171 family it supports |
|---|---|
| Repository access, least privilege, service identities | Access Control; Identification & Authentication |
| Pull requests, release approval, branch protection | Configuration Management |
| Pipeline logs, deployment records, RAIVS audit chain | Audit & Accountability; Security Assessment |
| Secret scanning and vaulting | Access Control; System & Communications Protection |
| Dependency, code, container, and IaC scanning | Risk Assessment; System & Information Integrity |
| Runtime Action Gateway (allow / ask / approve / block) | Access Control; Audit & Accountability; Configuration Management |
| Human approval for high-risk AI actions; separation of duties | Access Control; process accountability |
| AI tool approval and prohibited-data rules | Awareness & Training; Access Control; System & Communications Protection |
| Evidence retention and export | Audit & Accountability; Security Assessment |
| Blocked-action / exception handling | Incident Response; System & Information Integrity |
How the overlay attaches to each tier
- Build Readiness + overlay. Adds the CUI-boundary scope summary, the control-family mapping, an evidence-retention plan, and the external-provider review. This is the natural entry point for a CMMC-driven prospect.
- Launchpad + overlay. Adds change-to-ticket linkage, branch-protection and approval evidence, artifact hash/version tracking, an exception register, and the monthly evidence-export package.
- Governed Operations + overlay. Adds CUI-action classification, a prompt/output data policy, separation-of-duties evidence, and packaged action logs, verdicts, and exceptions for assessment.
**How to position it (say this, not more): **
These services help operationalize and evidence controls that support CMMC Level 2 readiness. Final applicability depends on the customer’s CUI boundary, SSP, shared-responsibility model, and C3PAO expectations. We do not say a service “satisfies” CMMC.
The CMMC / ISO 42001 bridge: For CUI, CMMC Level 2 drives the requirement (it aligns to the NIST SP 800-171 control set). For AI used outside the CUI boundary, ISO/IEC 42001 is the AI-governance framework we recommend — valuable, but not legally mandatory unless a contract, customer, or regulator requires it.
Verify before a meeting: CMMC assessment dates and rule phase-in details shift with rulemaking. Confirm any specific dates against current DoD / CMMC sources before putting them in front of a buyer. The structural claim (Level 2 aligns to NIST SP 800-171) is stable.
Notes for scoping & the PS-to-MRR motion
- Naming. The go-to-market names are Build Readiness → Launchpad → Governed Operations, with the Regulated / CMMC overlay as an add-on. Tier 1 was labeled “Foundation” in early drafts; “Launchpad” is now the single name used across the one-pager, the simulator, and this document.
- Populate before any prospect sees this. Every $[TBD] is a placeholder. Pull real figures from the current rate card; label modeled figures as base-case expected values, not forecasts.
- Sequence is the sell. Build Readiness (one-time PS) → Launchpad (recurring) → Governed Operations (recurring, regulated). Lead every Tier 0 with the two recurring conversion paths already in view.
- Don’t let Tier 0 borrow Tier 2’s language. Readiness sets up safely; it does not deliver live governance. Keep the SDK, engine, gateway, and RAIVS out of the Build Readiness scope in every artifact.
- Separation of duties is a requirement, not a feature. In Governed Operations, the builder cannot approve promotion or high-risk actions. This recurs across the AI SDLC work and should stay a hard line in the SOW.
- Cleanest first Tier 2 wedge. Regulated SMBs already on Launchpad — healthcare, finance, legal, and contractors who answer to an auditor, client, or insurer — are the natural first Governed Operations conversions. Scope a vertical-specific variant of the Tier 2 SOW for whichever of these lands first.
- Compliance language is “supports,” never “satisfies.” Regulated buyers get the same three offerings plus the Regulated / CMMC overlay (appendix) — one add-on, not a variant per framework. Say the services support CMMC Level 2 readiness; final applicability depends on the customer’s CUI boundary, SSP, and C3PAO. Keep the core definitions framework-free for the general SMB market.
- Template alignment. These SOW blocks are drafted to drop into Airiam’s corporate template (the AI_POV branding reference). Watch the same two things flagged on the Noble SOW: the title block and any stale year mark in the inherited header.
Sources grounding these definitions: the Build Safely one-pager (tier structure and pricing shape), the Governed Agent Services page (Action Gateway, RAIVS, native/MCP paths), and the governance simulator v1.0 (the exact tier-to-capability mapping — Tier 0 setup, Tier 1 build-time gates, Tier 2 runtime SDK/engine/gateway/RAIVS).