Seven decisions. Two cash lines. Platform already in client meetings.

What we are asking for

Three tiers. Total cash on today's ballot: $180,000 per year in cloud and AI NTE ($96K synthetic lab + $84K CUI pilot), plus 1099 surge authority of up to roughly $144,000 per year at full burn (120 hours per month at $100). Build labor is in-kind on KTG and Cyber overhead. Approve Phase A today: firm AWS transfer (scheduled next week), Entra, and Sentinel, with Decision 4 funding firm cloud billing at transfer. Charter and fund Phase B (CUI pilot, CGO priority). Note IL5 for later; not on today's ballot.

Today's EVP action: approve Tier 1 (Decisions 1–5), charter and fund Tier 2 (Decisions 6–7), note Tier 3 for planning. Decision 1 build labor is in-kind and the personal-account transfer is scheduled for next week. Decisions 2 (Sentinel) and 3 (Entra) are in working sessions with the CIO shop and KTG. Decision 4 funds firm cloud billing at transfer.

Context

For the last several months we have run a sandbox where we prototype AI and cyber capabilities, build client demonstrations, and prove what the firm can deliver before we commit a single billable hour. That sandbox produced the TECOM budget-to-readiness demo, our closest win and the template for pursuits like DHS, plus the Navy readiness demo now in front of real clients. It works. The problem is that it currently runs on a personal AWS account, which is the right way to move fast and the wrong way to run a federal firm's platform.

The fix is not to slow the platform down. The fix is to connect what we already have, the firm's CMMC-accredited GCC High environment and the AI Sandbox we built in AWS with this platform, into one governed story: corporate identity in, security telemetry out, and the sandbox on firm-owned cloud instead of a personal account.

What we have today

The firm has two footprints today. Corporate work runs inside a CMMC Level 2 boundary on Microsoft GCC High. Cyber and KTG built a separate AI Sandbox in AWS from the Pulumi stack in this repository: demos, prototyping, Bedrock and SageMaker experimentation, and this site. The sandbox is unaccredited and synthetic-data only. Billing still sits on a personal AWS account until ownership transfer next week (Decision 1).

flowchart LR
    subgraph CMMC["CMMC Level 2 · GCC High"]
        CORP[["Corporate environment
CIO · Entra · M365 G5"]]
    end
    subgraph SANDBOX["AI Sandbox · AWS"]
        LAB[["Pulumi platform
synthetic data · demos"]]
        DEMO(["Cognito
demo logins"])
    end
    ENTRA(["Entra ID Gov"])
    SENTINEL[["Microsoft Sentinel"]]
    ENTRA --> CORP
    ENTRA -. sign-in in motion .-> LAB
    CORP -. logs in motion .-> SENTINEL
    LAB -. logs in motion .-> SENTINEL
    LAB --> DEMO
        

The sandbox stays outside the CMMC boundary on purpose. Prototyping means constant change, and constant change inside an accredited boundary is what makes an accreditation hard to defend. The sandbox runs on synthetic and fixture data only, with no PII, no real client records, and nothing classified or CUI. When a capability needs real data or a client contract, it promotes out of the sandbox into a governed delivery path, not by growing more inside the personal account.

Where this goes: one platform, many client enclaves

The sandbox is today's footing. The plan is to extend the same discipline into a platform that hosts client data at federal impact levels and runs security operations for clients, which is where the real growth is. We do that without ever putting client-hosted data into the corporate CMMC boundary. Capability is built in the sandbox on synthetic data and promoted into separate accredited client environments through a controlled gate, never copied across.

flowchart TB
    subgraph DEV["AI Sandbox · unaccredited"]
        direction LR
        LAB[["Pulumi platform
synthetic data only"]]
        POL[["Security governance
NIST 800-171 baseline"]]
    end
    GATE{{"Mission gate
IaC rebuild · SBOM · client approval"}}
    LAB --> GATE
    POL --> GATE
    subgraph HOST["Trust zone: accredited client hosting"]
        direction TB
        subgraph TIERS["Impact tiers — separate accreditation each"]
            direction LR
            CORP[["Corporate CMMC L2
GCC High · no client data"]]
            COMM[["Commercial CUI
IL2 · FedRAMP Moderate"]]
            IL5T[["IL5 gold load
GovCloud · Azure Gov"]]
        end
        subgraph TENANT["Per-client stamp-out — dedicated account each"]
            direction LR
            CA[["Client A"]]
            CB[["Client B"]]
            CN[["Client N"]]
        end
        SHARED[("Shared baseline per enclave
Entra · IAM · KMS · segregated logs")]
        TIERS --> TENANT
        TENANT --- SHARED
    end
    GATE --> COMM
    GATE --> IL5T
    SIEM[["Sentinel SIEM / SOC
overwatch and MSSP"]]
    HOST -. one-way logs .-> SIEM
    CORP -. one-way logs .-> SIEM
    IDP(["Entra ID for Government"])
    IDP --> LAB
    IDP --> HOST
    IDP --> CORP
        

Hosting footprints (future, beyond today's two)

Today is GCC High plus the AI Sandbox. The plan adds accredited hosting footprints for client data: commercial CUI for state and civilian work, and an IL5 gold load for DoD. The corporate CMMC boundary we already hold stays separate from all client hosting. Each hosting footprint is its own accreditation boundary, sharing only operator identity in and one-way logs out with the rest of the firm.

Data type decides the tier, not the client. A state government is not automatically low-rigor. Criminal-justice data, federal tax information, and health data each carry overlays that sit on top of the base tier. Those overlays are built once, the first time a client needs one, and then reused.

Build once, stamp out per client

The IL5 environment is built as code and accredited as a single gold load. The system security plan, the control narratives, and the boundary diagrams are written one time against that baseline, not once per client. Each client then gets a fresh deployment of the same code with its own account, its own keys, and its own network, and it inherits the accredited posture by construction. Only the client-specific delta is assessed. One hard build becomes many client enclaves.

The promotion gate

The flow from the sandbox into a client hosting environment is the most important and most dangerous step in the architecture, because it crosses from an unaccredited synthetic environment into an accredited one. It is a promotion, not a copy. What moves is source code and infrastructure definitions, rebuilt clean inside the accredited baseline. Every capability that crosses gets a security review and an SBOM, and it runs on synthetic data in accredited staging until the client formally approves it for their workload. The sandbox never touches client data, and the client environment never runs unvetted code.

One security capability, two markets

The Sentinel capability we use in GCC High today, extended to sandbox and future client hosting logs, is the same service we would sell to clients as a managed security offering. It pulls one-way logs from every boundary into a single pane, and nothing flows from that pane back into client data. Internal overwatch and the client MSSP are one build serving two markets. Standing this up makes the firm an external service provider under CMMC and the DoD SRG, which is a determination to get in writing, with the operator-eligibility bar settled, before IL5 work is priced or committed.

CIO single pane over both environments

Decisions 2 and 3 are a CIO win, not a CIO burden. GCC High already has Entra ID for Government and Sentinel. The innovation platform ran outside that visibility on a personal AWS account. Wiring the sandbox into Entra and Sentinel gives the CIO the same governed identity and security spine across corporate and innovation, with one pane over activity that was previously a shadow platform.

The CIO organization is provisioning the firm AWS org with KTG (Decision 1, transfer next week) and governs the shared seams. Cyber and KTG build and sell from the platform; they do not replace enterprise IT. Demo and prospect access stays on Cognito and never enters Entra. That separation is deliberate.

Services this unlocks

The platform is not the product. The product is the menu of federal services it lets us sell. Thirteen core lines are grouped below by when revenue starts: six to win pursuits now, one to hand off after the win, and six recurring lines once hosting and managed security are live. Four companion lines in the revenue breakdown (managed ops, promotion-gate assurance, per-client compliance delta, and IL5 baseline build) sit with hosting and are documented on the costing page.

What this means for growth and delivery

The platform is the working expression of the firm's innovation and growth plan. It is built so that capability becomes demos, demos become qualified pipeline, and pipeline becomes services more than one team can sell and more than one practice can deliver.

Platform costing

Three budget lines on the roadmap, not three environments today. The firm runs two footprints now (GCC High and the synthetic lab). Phase B adds a commercial CUI pilot for client-data demos. IL5 accredited hosting is a separate future investment. The Innovation Lab stays synthetic throughout.

Overhead hours are planning NTE for KTG and Cyber capacity (first number KTG, second Cyber). Compliance SSP and intake sit on separate overhead, not in those totals. Decision 5 1099 covers shortfalls; Decision 7 raises that NTE during the pilot sprint. Full hour breakdown is on the costing page.

Anticipated questions