Architecture Assumptions
Design decisions, BCDR intent, Lumbra vendor risk, MuleSoft PCE constraints, and Diffuse-Discover-Deliver responses to the eight objections most likely to surface in technical and program office reviews.
Business Continuity and Disaster Recovery
The diagrams show Backup and Restore only for Boundary 02 (Salesforce Government Cloud Plus). No BCDR architecture is shown for the Game Warden enclave workloads. The table at right captures design intent per component.
Note on RTO/RPO targets: these are design intent, not validated commitments. A production BCDR plan requires tabletop exercises, runbook development, and validation testing within the classified environment. This is a mandatory deliverable before initial operating capability (IOC).
Lumbra Nebula Vendor Risk
MuleSoft PCE Licensing and Feature Scope
- Confirm the specific PCE version targeted and its feature availability matrix against the architecture's stated capabilities
- Confirm PCE pricing and procurement vehicle (GSA Schedule, SEWP, or direct)
- Confirm Kubernetes infrastructure provider (Game Warden, customer-provided, or Second Front-managed)
- Confirm PCE upgrade and patching responsibility (Salesforce, Second Front, or customer)
Common Objections and Responses
The eight objections most likely to surface in technical evaluation and program office reviews. Each is addressed in three steps: Diffuse (take the heat out), Discover (ask what's really behind it), and Deliver (the substantive response). Click any card to expand.
The diagram earns its density. No component was added for elegance. Each one exists because a specific capability gap required it.
How many systems does your team touch today to produce a single target package? How many are integrated, and how many require a human to re-key data from one to the next?
The architecture shows approximately 15 named components because it replaces 5 to 7 disconnected systems and adds an authorization fabric and agentic layer. Each component has a single job.
The ISSO and CAB concern has a specific answer: Second Front's Game Warden is a continuous ATO (cATO) environment. Each container gets an ATO as part of the platform boundary, not through a separate program review. The customer submits one system boundary, not 15. Second Front has operationalized this model across multiple programs. The apparent complexity is in the problem, not in what this architecture invented.
Fair. "CRM" is the wrong frame and Salesforce should retire it for mission contexts. The label creates a false premise before the conversation starts.
What does your team currently use to track the lifecycle of a target development package from first report through action and final disposition? Who owns that record, and what happens to the institutional knowledge when the analyst who built it rotates out?
Sales Cloud is being used as a mission workflow OS, not a sales tool. What it provides: record lifecycle management for targets, sources, and operations; Flow-enforced process steps that cannot be skipped; role-based visibility scoped to clearance and need-to-know; an audit trail from first record creation; and a stable API every component can write to.
The IC has tried Access databases, SharePoint, custom GOTS, and home-built case management. The problem is always the same: who owns the record, who sees which parts, and where does institutional knowledge go when the team rotates. Sales Cloud solves all three in a FedRAMP-authorized, IL5-certified platform with commercial support.
This is exactly the right question. If the Salesforce portfolio were complete and available at IL5 in-enclave deployments today, this architecture would look materially different and be significantly simpler.
When do you need operational capability? This fiscal year? FY27? The answer changes which architecture is correct.
Data Cloud and Agentforce do not currently have IL5 ATO for in-enclave, air-gapped deployment. The compensatory stack exists because the Salesforce portfolio has not yet closed those gaps for classified environments. This architecture is built on what is available, cleared, and deployable today.
If the Salesforce national security team advances Data Cloud and Agentforce to in-enclave IL5 deployment, the compensatory architecture shrinks substantially. That is a business case conversation worth having, and the roadmap questions document frames it explicitly.
It is a single path by design. This was an explicit architectural decision, not an oversight.
What is your current cross-boundary call path? How many paths exist today, how many are fully audited, and how many apply consistent policy enforcement on every call?
Every enterprise integration platform has a central hub or it has a mesh. A mesh of point-to-point connections between four accredited boundaries means inconsistent authentication, partial audit coverage, and no single place to enforce or change policy. A mesh also fails silently and asymmetrically.
MuleSoft is not just a reliability choice. It is the policy enforcement point for every cross-boundary call. Removing it means removing ABAC enforcement, JWT pass-through, named credentials, and per-call audit from every integration path simultaneously. MuleSoft is the mechanism by which the architecture keeps its promises about authorization and audit.
A fully deployed version of this architecture is not a 90-day sprint. That is an honest statement.
When was the last time your program delivered a working integrated capability in under 12 months? What were the blockers, and are those blockers present here?
The architecture phases naturally. Phase 1 deploys Sales Cloud, MuleSoft PCE, and the ABAC fabric. Working mission record management system with policy-enforced cross-boundary access. Timeline: 6 to 9 months to first working capability.
Phase 2 adds the sovereign data pipeline. Phase 3 adds the Lumbra Nebula agentic layer. The 9-minute target package flow is Phase 3. But Phase 1 alone replaces whatever Access database or SharePoint the program is currently using, with commercial support and a continuous ATO. The program sees value before paying for Phase 3.
The cost question is completely legitimate and the number is real. This is not an inexpensive platform.
What does the current fragmented stack cost in licensing, integration contracts, custom development, and analyst hours per year? What is the fully loaded cost per target package today, including the time it takes to produce one?
The largest cost variables: MuleSoft PCE (premium over Runtime Fabric), Salesforce Government Cloud Plus (full Sales Cloud licensing), and Lumbra Nebula (cleared startup pricing with limited competitive pressure). Snowflake, Elastic, Airbyte, and Airflow are substantially less expensive than the Informatica IDMC or legacy data warehouse alternatives they replace.
The TCO argument has three legs: (1) this platform replaces 5 to 7 separate contracts, (2) it reduces analyst hours per target package from roughly 9 hours to under 9 minutes across every package the program produces, (3) Second Front's Game Warden bundles ATO and security operations overhead into the platform cost. A precise cost model requires target volume, user count, and data volume.
If Palantir is delivering operational value, that is a real data point and it should be on the table.
Who owns your data? Is it in Palantir's ontology or in your systems? What are the costs and the timeline if you need to move off the platform or re-compete the contract?
Palantir is a capable product. It is also a proprietary data model: your data lives in Palantir's ontology, not in a customer-owned warehouse. Exit costs are catastrophically high by design, which is a known and intentional element of their business model. Palantir AIP does not currently operate in C2S.
This architecture takes the opposite position. Data stays in customer-owned Snowflake and Elastic. Every commercial component is replaceable. Salesforce is the accountable prime but is not the platform monopoly. The right question is not which platform to pick but which data model the program wants to own long-term.
The cleared support model is often more consequential than the technology choices, and it is a reasonable objection to raise early.
What is the current support model for the program's existing stack? How many of those vendors have cleared support staff on contract today, and what are the response time commitments?
The support accountability structure: Salesforce as prime owns accountability for the integrated platform and serves as the single throat to choke. Second Front owns Game Warden operations including cleared staff, continuous ATO management, and underlying infrastructure. Each named subcomponent vendor is responsible for tier-2 support under the prime contract.
Cleared technical staff exist at Snowflake Government and Elastic Federal. Astronomer has federal practice experience. Lumbra Nebula is the most operationally unproven on the cleared support dimension and that risk is acknowledged in Section 2. This is not a stack that requires the customer to develop cleared expertise across eight products. Salesforce prime accountability is the design choice that makes this a managed service.