Internal · Working Session · August 2026 · Revision 2

The Sovereign Factory,
asked and answered.

Seven questions that define what we build. Each schematic is a proposed answer — the "open for debate" line under each is where the conversation continues. Direction locked: Apolo doesn't build the org's apps; Apolo is the sovereign factory where the org — its people plus AI agents — builds its own. And Apolo is not a service the org reaches out to. Apolo is installed inside the organization.

Companion to Apolo_Repositioning_Sovereign_Sandbox.key · incorporates the DRR model (H.M., board) · demo assets referenced from the AI Launchpad kit

What changed in this revision

Rev. 1 drew Apolo as an outside party with a pipe reaching into the customer. Wrong model. We install inside the org and connect the org's resources over secure VPN so that leased racks, cloud capacity and remote sites all fall inside one cohesive internal perimeter. The VPN doesn't punch a hole in the wall — it extends the wall around more ground.

Consequence for the data story: there is no vendor telemetry pipe. What exists is an insight module in a hardened enclave inside the org. It reads full-fidelity data locally, publishes only anonymized distributions outward, and reads fleet-level reference data back in so the org never has to leave its own perimeter to get an answer. Q4 is rebuilt entirely around this; Q2 is new.

Q1 · The Product

What are we actually selling now?

Three layers, one story, all of them installed on the customer's side of the wall. The Ground is the deck's sovereign contour — paid infrastructure, the Series A line. The Factory is the new middle: auto-provisioned sandboxes for the whole org, and the org's own catalog where finished apps land. Apps themselves cost nothing — they're the exhaust, not the product. The Intelligence layer is the data story, and it runs in-perimeter too: the portal is a tenant of the org's contour, not a cloud they log into.

VALUE MOVES UP INSIDE THE ORG'S PERIMETER — ALL THREE LAYERS, INSTALLED INTELLIGENCE — THE DATA STORY Insights portal · org AI P&L · redeploy / pricing / security recommendations Computed in-perimeter on full-fidelity data — the portal is a tenant, not a cloud FACTORY — AUTO-SANDBOX FOR THE WHOLE ORG Humans + AI agents build the org's apps · promotion gate · the org's own catalog Launchpad inverted: their shelf, not ours · golden templates seed it GROUND — THE SOVEREIGN CONTOUR Own compute · own open models · every site stitched by VPN into one contour Ephemeral jobs · vclusters · vLLM serving · air-gap installer — already built WHO PAYS DRR — monthly / per query from OpEx · the raise headline Apps: $0, unlimited one-time setup fee Platform subscription infrastructure ARR · stays paid Nothing here is a weekend build — and the top layer only exists because the middle one runs on the bottom one, in their building.

Open for debate — do we name the middle layer "Factory" externally, or keep "Sovereign Contour" as the umbrella and let the factory be its verb? Naming decides the deck's spine.

Q2 · The Deployment

Where does Apolo actually live?

Inside. Apolo is software the organization installs, on the organization's Kubernetes, under the organization's identity provider, on the organization's keys. Compute that isn't physically in the building — leased GPU racks in a partner DC, private cloud capacity, a plant on the other side of the country — is joined by secure VPN into one cohesive internal perimeter. That is the whole trick: the tunnel extends the wall rather than piercing it, so the CISO reviews one perimeter instead of five vendor integrations. Apolo-the-company sits outside it with no data plane and no standing access; what flows in is signed release bundles, pulled on the org's schedule through the org's own gate.

APOLO, THE COMPANY — OUTSIDE THE WALL · NO DATA PLANE · NO STANDING ACCESS Ships signed release bundles: platform images · model weights · policy packs · golden templates. You pull them, on your schedule. Support is break-glass — you open it, it is time-boxed, screen-shared, logged, and then it closes. ARTIFACT GATE · INBOUND ONLY ONE COHESIVE INTERNAL PERIMETER — STITCHED, NOT PIERCED HQ / PRIMARY DATA CENTRE APOLO — INSTALLED HERE not a service you dial out to · control plane + scheduler · model registry + serving · factory + org catalog · policy engine + audit log · insight module (see Q4) Runs on the org's Kubernetes, the org's IdP, the org's keys. Air-gapped install is the same install. COLO / PARTNER DATA CENTRE Leased GPU racks · burst training and serving — inside your contour, not the provider's tenant CLOUD VPC — PRIVATE LINK Elastic overflow capacity · no public endpoint, no public egress path, no shared control plane PLANT · CAMPUS · REMOTE SITE Inference next to where the data is born · same identity, same policy set, same audit log REGULATED / AIR-GAPPED ENCLAVE Tighter policy, zero outbound — still one catalog, one control plane, one operating model THE VPN IS INTERNAL PLUMBING — IT EXTENDS THE WALL, IT DOES NOT PUNCH THROUGH IT Encrypted overlay · org-owned keys · mutual TLS between sites · every link terminates on both ends inside the contour To the CISO: one perimeter to defend — not five vendor integrations to review, and no third-party tenancy to audit. The correction: Apolo was never meant to sit outside and reach in. The org installs it, and the contour grows to cover whatever compute the org attaches to it.

Open for debate — do we ship our own overlay mesh (WireGuard-class, keys handed to the customer) as part of the install, or ride whatever SD-WAN/MPLS the org already runs? That choice decides who our buyer is inside IT — the platform team or the network team — and how long the install actually takes.

Q3 · The Factory

How does an app get born?

Two lanes into one machine, and every step of it inside the contour. The guided lane is the Crimson CFO: describe the tool in plain language, the scaffolder does the heavy lifting inside a sandbox already wired to org models, org data and org policy. The power lane is the org's engineer with full harness choice. Everything exits through one promotion gate — SSO wrap, audit, security scan, owner sign-off — and lands on the org's shelf. Because every attached resource is inside the same perimeter, where a sandbox runs is a capacity decision, not a security decision.

INSIDE THE CONTOUR — NO STEP OF THIS BUILD PATH LEAVES GUIDED LANE Business builder "I need an RFI tool" — describes, reviews, ships POWER LANE Org AI engineer Full harness choice, custom pipelines AUTO-SANDBOX · ONE-CLICK SPAWN Agent harness Scaffolder copilot Big brain, in-perim. Small brains, in-perim. Org context / RAG Secrets broker Egress: deny first Telemetry stays local Claude, Codex, or an open harness — the org picks; the walls and the models are the org's either way. PROMOTION GATE · SSO wrap · Audit hooks · Security scan · Resource caps · Owner sign-off vibe-code, governed THE ORG'S CATALOG RFI tool MTR checker Site photos + whatever's next their shelf, not ours telemetry loops back inside the wall — app #12 makes the factory better at #13 SANDBOX PLACEMENT — ANY ATTACHED RESOURCE, THE SAME WALLS The scheduler drops the sandbox wherever capacity is: HQ rack, colo GPU, cloud VPC, edge node. All of them sit inside the contour, so placement is a capacity decision — not the six-week security argument it is everywhere else. v1 maps onto the existing stack: ephemeral jobs + vclusters = the sandbox · Launchpad = the catalog shell · Apolo Analytics = the insights seed.

Open for debate — the promotion gate is where enterprises will judge us: how heavy is v1 governance (full approval workflow vs. sign-off checkbox)? And do we show both builder lanes in the mockup, or lead guided-only for emotional punch?

Q4 · The Perimeter

What does Apolo actually see?

Nothing. Apolo-the-company has no view into the org's systems, because there is no pipe from their systems to ours. What exists instead is an insight module in a hardened enclave inside the org, operated by the org. It reads full-fidelity telemetry locally and publishes only anonymized distributions — rates, ratios, binned shapes, threshold-gated — through a release gate the org's own admin signs. The same module reads fleet-level reference data back in, so the org gets comparative answers without anyone leaving the perimeter to ask. This is what makes Herb's data agreement signable: not a promise about restraint, an architecture where the raw material physically has nowhere to go.

ORG PERIMETER — EVERYTHING OPERATIONAL LIVES HERE Raw data documents · records telemetry at full fidelity Models big brain + small brains pinned, upgraded on purpose Factory + catalog sandboxes · prompts · code apps · audit trail · secrets "MY OPS" — full-fidelity insights, computed here and consumed here every question answered at maximum resolution, because nothing ever had to leave scenario modelling runs against the org's own complete history INSIGHT MODULE — SEGREGATED ENCLAVE, IN THE ORG, RUN BY THE ORG The only component with a path across the wall. It reads full fidelity and publishes statistics. WHAT GOES IN every event, every trace, every token — unredacted, local only WHAT COMES OUT distributions · rates · ratios k-gated · noised · no records NEVER LEAVES, BY CONSTRUCTION: raw data · prompts · code · business content · file names · identities · anything re-identifiable "No pipe reaches in. A module in your building publishes statistics — and reads the fleet's back." RELEASE GATE admin-signed → distributions out ← benchmarks back APOLO FLEET LAYER assembled only from what orgs choose to publish Fleet benchmarks give-to-get · DSSA-governed Scaffolder training patterns, never payloads Templates + policies distilled · certified · resellable The corpus how enterprises really build and run sovereign AI LINEAGE BADGE — on every answer: "computed inside your perimeter · only anonymized distributions were ever published"

Open for debate — two knobs, and both are the DSSA conversation. First, governance: does the admin sign every release, or set a standing policy with periodic review? Second, the anonymization parameters — k-threshold, bin widths, noise — do we publish them openly as a trust move: "here is everything that can ever be computed, and here is the floor it is blurred to"?

Q5 · The Data Asset

Where does the compounding data story come from?

Two flywheels, both spinning inside the customer. The ops flywheel turns runtime telemetry into sold recommendations — redeploy resources, fix pricing, harden security. The build flywheel turns build traces into a smarter scaffolder. Both feed the org's own full-fidelity corpus, which never moves. The fleet corpus is a second, thinner thing: assembled purely from the distributions orgs publish, one signed release at a time. It grows more slowly than a telemetry pipe would — and it is the only version of this asset an enterprise will ever agree to. Nobody else has it: the labs see API calls, Copilot and Cursor see editors; nobody sees whole-org build-and-run inside enterprise perimeters.

INSIDE YOUR PERIMETER OPS FLYWHEEL run apps → telemetry → scenario models → recommendations → better ops → more usage sells: redeploy · pricing · security posture BUILD FLYWHEEL build apps → traces → train the scaffolder → one-shot builds → more apps built cuts setup COGS · shrinks time-to-live YOUR CORPUS full fidelity · in-perimeter · does not move INSIGHTS PORTAL — RUNS INSIDE org AI P&L · cost per task · what-ifs recommendations · billed monthly (DRR) INSIGHT MODULE — THE WAY OUT anonymize · aggregate · k-threshold admin reads it, then releases distributions only OUTSIDE — THE FLEET Fleet benchmarks — DSSA give-to-get Templates & policy packs — resellable THE FLEET CORPUS built only from what orgs publish one signed release at a time Cold-start honesty: at N≤3 orgs the fleet corpus is an empty room. Day-one value is the in-perimeter portal — scenario modelling on the org's own complete history. Benchmarks light up later, as published releases accumulate. Sell the mechanism, not the projection.

Open for debate — synthetic data's third act: distilled synthetic app-templates and workload traces sold to hardware partners and DC operators for capacity planning. In or out of the story for the raise? And the harder one: with publication org-gated, our corpus growth rate is a function of how many admins press the button — do we underwrite that with a pricing incentive, or leave it to the benchmark give-to-get?

Q6 · The Money

Who pays for what — and what does the raise lead with?

Herb's mechanics, mapped honestly onto the factory. Apps go to zero forever — radical, and nobody can undercut it, because the org builds them itself. The ground stays paid: that's the infrastructure ARR the deck already claims. The DRR line is the raise headline — recurring answers from OpEx, delivered by a portal that runs on their own metal.

GROUND Platform subscription annual · capacity-based the infrastructure ARR grows as sites attach never free — hold this line INSTALL + FACTORY One-time fee install · attach sites · config ≈ today's customization fee scaffolder eats this cost → setup becomes margin APPS $0 unlimited, forever the org builds them — "Claude will build it for free" stops being an objection: it's the product now INTELLIGENCE Insights — DRR monthly or per query · OpEx portal runs in their perimeter org AI P&L · what-ifs benchmarks via published data once decisions run through it, you are unremovable INVESTOR LENS Agent-subscription ARR: low multiples, leaky faucet. DRR: claimed 20–50× (Herb). The raise leads with the mechanism — installs live, sites attached, DSSAs signed, published releases accruing — not projected revenue. Existing agent contracts regear now, while there are fewer than ten — Herb's own argument for why this is the cheapest moment to do it.

Open for debate — does the 2026 money slide move the $1M+ target to install + platform + DRR with the agent line at zero? And do we show Herb illustrative DRR math (20 orgs × $3–5k/mo portal) or let him do that arithmetic himself in the room?

Q7 · The Mockup & The Demo

What do we mock this week, and what do we demo live?

One continuous HTML walkthrough, three scenes, all of it framed by a visible perimeter — the chrome itself is the argument. And one live demo that weaponizes the concession: rebuild MTR CrossCheck inside the factory, in twenty minutes, from the same Artrom PDFs in the sales demo kit. Slide 03's threat becomes the product demo.

MOCK CHROME — EVERY SCREEN SITS INSIDE A VISIBLE PERIMETER FRAME persistent status line: compute · your contour | egress · deny by default | published artifacts · 0, until you sign one SCENE 1 · THE FACTORY "Describe the tool you need." sandbox spawns on whichever site has GPU scaffolder drafts · builder reviews promotion gate runs its checks the emotional beat: it's building SCENE 2 · THE ORG'S SHELF Their catalog, their apps. Launchpad skinned as the org's own new tile lands next to golden templates SSO'd · audited · resource-capped the trust beat: governed, not shadow IT SCENE 3 · THE INSIGHTS Their AI P&L, computed inside. apps built · usage · cost per task "Publish this month's distributions?" → admin sees the exact artifact, then signs the money beat: this is the DRR THE LIVE DEMO — CONCEDE AND WEAPONIZE (20 MIN) Artrom MTR PDFs in → factory builds an MTR checker before their eyes → lands on the shelf → portal registers the build, the cost, the usage "Anyone can rebuild our apps in a weekend" — yes. In here, your team does it in twenty minutes, and the PDFs never left the room. That's the product. Mock — this week Herb review Aligned C-level demo Design partners + DSSA SKU → raise argovis.io his 2–3 mo prototype window CTO/CIO audience first published releases deck 30/60/90 intact

Open for debate — skin the mock as a DC-builder org (Aligned-ready) or vertical-neutral with a toggle? And does the live-demo promise (20 minutes, real build) go into the mock as a claim, or stay verbal until we've timed it on the real stack?

The Q&A Queue

Open questions, in decision order

Each of these changes what gets mocked or what gets said to Herb, Bill, or Aligned. Answer in any order — the mock starts moving on #6 and #7 immediately.

  1. Naming — "Sovereign Factory" as the layer name, or keep "Sovereign Contour" as umbrella with the factory as capability? (decides deck spine + mock header)
  2. VPN posture — ship our own overlay mesh with the install, or ride the org's existing SD-WAN/MPLS? (decides the install playbook, the buyer inside IT, and time-to-first-sandbox)
  3. Insight-module governance — admin signs every published release, or standing policy with periodic review? (decides the DSSA text and scene 3 of the mock)
  4. Anonymization parameters — publish the k-threshold, bin widths and noise settings openly as a trust move? (decides the lineage badge's claim and how fast a CISO clears us)
  5. Air-gap variant — with zero outbound, does the insight module publish by offline media, or does that site simply never contribute? (decides the government / defence / regulated pitch)
  6. Promotion gate weight — v1 governance: approval workflow, or checkbox sign-off? (decides CISO story vs. speed story)
  7. Mock skin + builder lanes — DC-builder org (Aligned-ready) or neutral with toggle; guided-only for punch, or both lanes? (decides scene art, sample apps, portal queries, scene 1 script)
  8. Money slide — move the $1M+ 2026 target to install + platform + DRR, agent line to zero? Show Herb the DRR math or let him do it? (decides the board conversation)
  9. Synthetic resale — templates/traces to hardware + DC partners: in the raise story or held back? (decides slide 09/10 edits)