Flagship synthesis

Title: Building an AI-native business platform in Microsoft's ecosystem without surrendering portability, customer ownership or human accountability

Research cut-off: 2026-08-24Disclosure: This synthesis and all source panels are AI-based analytical work. The professional roles are analytical lenses; no human expert consensus is claimed. The financial-services implementation is treated only as anonymized feasibility evidence. No private customer, account, partner, negotiation or tenant information is used.

Labels:

• [FACT] Directly supported by primary documentation, legislation or published empirical research.
• [INFERENCE] Reasoned conclusion from the evidence.
• [RECOMMENDATION] Proposed action requiring validation.
• [DECISION] Proposed governance choice for Dataheart.

Consolidated conclusion

[DECISION] Do not authorize a broad Launch Factory launch, Microsoft-led growth plan, production-write authority or scaled fleet of isolated cells. Authorize a paid falsification programme: one independent EU customer, one recurring workflow, read-only or shadow mode, fixed scope, real price, explicit baseline, and predetermined stop conditions.

The opportunity remains plausible, but six linked bets are unverified:

1. A distinct enterprise category will receive budget.
2. Buyers will prefer Dataheart to native Microsoft and incumbent combinations.
3. Marketplace will shorten procurement rather than merely settle known demand.
4. Customer cells can preserve software economics.
5. Enterprise committees will accept another decision-and-action layer.
6. Forward-deployed engineering will become a repeatable product.

No reviewed evidence establishes an independent, paid, clean-room Dataheart outcome, renewal, sustainable price, repeatable deployment or contribution margin. The anonymized implementation is therefore an existence signal—not proof of value, repeatability or market demand. This is the shared conclusion of the evidence-integrity audit and independent verification; the commercial red team goes further and recommends no scale funding until paid falsification succeeds [P11–P13].

The surviving proposition is narrower:

What the research changes in Launch Factory

Original direction	Research change
Broad AI-native business platform	Sell one recurring evidence-to-decision workflow; keep the platform architecture mostly invisible.
Marketplace as first distribution engine	Treat Marketplace as an optional procurement, billing and entitlement rail after a sponsor and budget exist.
“Private transactable preview”	Separate DEV preview testing from commercial production. For a non-public first sale, use a live private plan; use a private offer only when an acceptable public transactable base exists.
Dedicated cell for every tenant	Make cell isolation a priced assurance tier. Share only components with an explicitly accepted failure and compromise radius.
AI-led operation	Treat the model as an untrusted proposer. Deterministic policy and accountable humans authorize; scoped identities execute.
Portability by architecture	Require a self-describing export, neutral verifier and second-target restore/replay before claiming portability.
FDE work as product learning	Count an artifact as product only after second-context reuse, tests, a non-founder runbook and no core fork.
Cross-customer learning	Default to tenant-local learning. Share only consented schemas, tests, adapters and aggregated benchmarks—not raw customer content.
Launch KPIs	Replace listings, demos and generated activity with paid commitments, cycle-time and quality effects, reviewer burden, repeatability, contribution margin and exit performance.

[DECISION] Rename the operating phase internally from “launch” to “paid falsification.” The Launch Factory hypothesis is changed rather than wholly rejected: the factory should manufacture evidence of repeatability, safety, value and exit—not merely tenants and Marketplace artifacts.

Market and opportunity map

No defensible TAM can be calculated. Use named-account arithmetic:

reachable opportunity = qualified accounts × paid-conversion probability × tested annual price

All terms remain assumptions until supported by auditable funnel and contract evidence.

Zone	Opportunity	Qualification	Disqualifier
Primary beachhead	EU evidence-intensive operational exceptions, supplier/ICT-risk decisions, access-policy exceptions and controlled change	Recurs at least quarterly; named process and economic owners; measurable baseline; reversible or read-only start; two or more authoritative sources	No budget owner, no baseline, one-off analysis, or demand for immediate autonomous action
Adjacent	Regulated assurance, audit reconstruction, remediation and incident closure	Outcome observable within 30–90 days; buyer values evidence and exit	Native stack supplies the required result at materially lower cost
Ecosystem	Certified adapters, workflow packs, policy mappings, conformance tests and privacy-safe benchmarks	Reuse lowers onboarding effort without customer-data leakage	Partner customization creates forks or permanent support liability
Later option	Customer-managed or second-cloud cells	Paid sovereignty or concentration-risk demand	Portability cost exceeds willingness to pay
Avoid	Generic AI governance, catalog, search, control tower or agent platform	—	Strong overlap with Microsoft Foundry/Purview, ServiceNow, Palantir, Collibra and Databricks [P10–P13]

[INFERENCE] Sweden and the Nordics are good falsification environments because digital adoption and institutional scrutiny are high, but readiness is not willingness to buy. EU law strengthens the relevance of traceability and switching while also increasing acquisition and assurance costs. Sweden’s Cybersecurity Act has applied since 15 January 2026, subject to entity and service scope (Swedish law).

Buyer decision chain

Marketplace touches only part of the purchase:

1. Workflow user validates usefulness and workload.
2. Process owner defines the baseline and operational outcome.
3. Economic buyer owns the budget and renewal threshold.
4. Data owner authorizes each source and purpose.
5. CISO and architecture approve isolation, identity, recovery and support access.
6. DPO, legal and AI governance assess roles, lawful basis, rights, retention and affected-person safeguards.
7. Procurement and vendor risk approve terms, audit, subprocessors, continuity and exit.
8. Azure billing authority accepts the commercial product.
9. Azure subscription authority purchases or subscribes.
10. Entra administrator approves application access where required.
11. Operations accepts support, incidents, SLOs and rollback.
12. Human decision owners accept responsibility and the ability to reject.
13. Affected people need explanation, correction and contest routes.

[FACT] Private-offer acceptance, purchase and SaaS activation are separate acts and may involve different roles (Microsoft private-offer overview).[INFERENCE] A Marketplace listing cannot collapse the enterprise decision chain; it can only reduce selected transaction steps.

Before FDE work starts, require a three-person core: process champion, economic buyer and technical/risk approver.

Product-to-Marketplace/co-sell/customer-outcome path

1. Qualify: one recurring workflow, named authority, usable evidence, baseline and budget.
2. Baseline: record total cycle time, active handling and review time, evidence completeness, defects, reversals, appeals and downstream outcomes.
3. Paid shadow pilot: recommendation-only; no production writes.
4. Verify the product: adversarial isolation, product lockbox, recovery, deletion, entitlement reconciliation and portability drills.
5. DEV commerce test: separate preview offer with nominal amounts. Preview is a pre-publication test state (Microsoft SaaS planning).
6. Choose production route:
   • Live private plan when the first sale must remain non-public.
   • Public transactable base plus private offer when public availability is acceptable and negotiated economics are required. Private offers require publicly transactable plans (private-plan guidance, private-offer FAQ).
   • Direct contract when Marketplace adds friction or the buyer lacks the required Azure path.
7. Activate only after a usable cell exists. Reconcile Marketplace state with Dataheart’s internal entitlement ledger.
8. Observe customer outcome: compare against the predeclared baseline; include human burden and harm.
9. Replicate: require a second independent tenant, non-founder operation and no core fork.
10. Co-sell-ready: pursue only after the live-offer and collateral requirements are met.
11. Azure IP co-sell/MACC: treat as later-stage upside. Microsoft currently requires, among other conditions, USD 100,000 trailing-12-month Azure consumed revenue or Marketplace billed sales, Azure platforming and technical validation; Azure IP co-sell is a prerequisite for MACC eligibility (co-sell requirements).
12. Partners: add only after support, authority, margin and artifact-conformance boundaries are explicit.

[FACT] Marketplace documents a standard 3% service fee while the publisher bears hosted infrastructure cost (transaction guidance).[DECISION] Marketplace publication, certification, co-sell status and Microsoft interest are not commercial outcome KPIs.

Dataheart core versus Microsoft profile

Dataheart portable core	Microsoft ecosystem profile
Canonical tenant, subject, role and workload identities	Entra tenants, objects, applications and OAuth flows
Source contracts: ownership, purpose, schema, semantics, freshness and rights	Graph, SharePoint, Fabric, SQL and other connectors
Meaning and policy with stable provider-neutral identifiers	Microsoft-specific mappings and policy adapters
Evidence, provenance, corrections and dissent	Azure storage, event and observability implementations
Recommendation envelope and uncertainty	Azure model/Foundry adapter
Deterministic authorization and separation of duties	Entra authorization inputs and Azure action adapters
Controlled-action contract, idempotency and rollback	Azure/Graph/Power Platform execution
Receipt and outcome ledger	Azure-hosted ledger implementation
Internal entitlement and meter journal	Marketplace offer, plan, subscription, webhook and billing mapping
Product lockbox, break-glass and incident RACI	Azure PIM/Lockbox/Sentinel integrations
Export, neutral verification and restore contract	AKS, Azure SQL, Key Vault and regional deployment choices
Customer-owned policy and human authority	Microsoft as infrastructure, identity, commerce and distribution provider

[FACT] A shared Azure OpenAI resource does not provide security segmentation between model deployments; the application must enforce tenant-to-deployment access (Azure OpenAI multitenancy).[DECISION] No Azure, Entra, Marketplace or model-provider identifier may be the canonical authority for a Dataheart object.

Strongest supported claims

1. Marketplace is a procurement rail, not evidence of demand. Supported across P01–P13 and directly by the distinction between preview, private plans, private offers and co-sell gates.
2. A private preview is not a production commercial state. Microsoft recommends DEV preview testing with nominal amounts.
3. Cells trade isolation for cost and fleet complexity. Azure explicitly documents this trade-off (Azure multitenant approaches).
4. Portability is more than container mobility. It includes semantic, policy, identity, behavioural, evidentiary and operational equivalence [P07,P11,P13].
5. Receipts support reconstruction, not truth. W3C PROV and SCITT provide provenance and signed-statement structures, not substantive correctness (PROV-O, RFC 9943).
6. AI productivity is workflow-dependent. Published studies show benefits inside bounded tasks and worse results in some settings or outside capability frontiers (QJE field study, Organization Science experiment).
7. Human approval is not proof of superior performance. A meta-analysis found human–AI combinations better than humans alone on average but worse than the better independent party overall, with decision-task losses (Nature Human Behaviour).
8. Regulation creates both demand and friction. DORA, the Data Act, GDPR and the AI Act support traceability, accountability and switching, while adding diligence, contracting and operational obligations (DORA, Data Act, GDPR, consolidated AI Act).
9. Generic AI-governance positioning is weak. Microsoft already claims inventory, observability, policy, compliance, security and cost capabilities in Foundry Control Plane, although some capabilities remain vendor-asserted or preview (Microsoft Foundry).
10. No Dataheart observed outcome exists in the reviewed public-safe evidence.

Strongest objections

The following remain equal-status alternatives, not footnotes:

• No demand: buyers may find the architecture interesting but fund only a narrow service or nothing.
• Native absorption: Microsoft or an incumbent may deliver 80% of the result under an existing agreement.
• Cell-economics failure: idle capacity, security operations, backups, recovery and support may make the product a managed-service fleet.
• FDE non-repeatability: customer-specific meaning and policy may resist productization.
• Committee friction: the product adds another supplier, authority layer and incident relationship.
• Review tax: evidence checking and human approval may eliminate the productivity gain.
• False assurance: detailed receipts may legitimize wrong or unfair decisions.
• Surveillance and accessibility harm: logs and review metrics may burden or monitor workers and exclude affected people.
• Portability nobody funds: exitability may remain unpriced insurance.
• Weak network effects: tenant secrecy may prevent useful cross-customer learning; partner customization may create an anti-network.
• Regulation as cost: legal and assurance obligations may increase acquisition cost faster than they create budget.
• Microsoft incentive conflict: Microsoft benefits from Azure consumption while building overlapping functionality.

Open decisions

1. First workflow: supplier/ICT-risk exception, identity-policy exception or operational change approval.
2. Production commercial route: private plan versus public base plus private offer.
3. Isolation tiers: dedicated data/action plane only, full stamp, customer-managed cell or pooled stamp.
4. Minimum acceptable contribution margin and support hours.
5. Price and pilot-credit policy.
6. Which Microsoft services are replaceable launch conveniences versus prohibited authority dependencies.
7. What evidence may be retained in receipts and for how long.
8. Product-lockbox and incident-accountability model.
9. Neutral second target and maximum acceptable exit cost.
10. Conditions for partner certification and reusable artifact governance.
11. Whether buyers will pay for portability or only immediate workflow outcomes.
12. Stop, specialist-service or product path if repeatability fails.

Experiments

The campaign’s highest-priority experiments are:

1. Real-price and problem test with twelve qualified organizations.
2. Buyer-chain validation with user, risk approver and economic buyer interviewed separately.
3. Marketplace-versus-direct comparison across six comparable opportunities.
4. DEV Marketplace lifecycle chaos test with at least 200 malformed, duplicated, delayed and reordered events.
5. Paid EU clean-room pilot with baseline and assisted cases.
6. Human-only versus AI-shadow versus human-plus-AI comparison.
7. Equal-budget native-stack bake-off.
8. Second-tenant, non-founder reproduction.
9. Full-path two-tenant isolation attack.
10. Product-lockbox and break-glass drill.
11. Cell/fleet contribution-margin and support study.
12. Backup, restore, deletion and incident exercise.
13. Non-Microsoft export, restore and receipt replay.
14. Type-coercion torture test for mixed data estates.
15. Shadow-meter reconciliation and buyer-comprehension test.
16. Accessibility, contestability and participation-integrity evaluation.
17. Reversible-action safety and abstention trial.
18. Partner and reusable-artifact experiments.

All are planned and not run. Detailed gates appear in the graph payload.

30/90/180-day roadmap

By day 30

• Freeze one ICP, workflow, authority model and explicit exclusions.
• Establish baseline and gold-case data.
• Freeze portable contracts for source, meaning, policy, evidence, recommendation, authorization, action, receipt, outcome and export.
• Publish the full cell boundary and shared-dependency inventory.
• Define Dataheart’s product lockbox, break-glass and incident RACI.
• Build the complete cost ledger and one fixed pilot/annual price card.
• Create a separate Marketplace DEV preview.
• Pre-register experiments and stop rules.
• Run the native-stack bake-off before expanding Microsoft integration.
• Keep all actions read-only or sandboxed.

By day 90

• Secure one genuinely paid independent EU pilot.
• Complete lifecycle chaos, isolation, support-access, recovery, deletion and entitlement tests.
• Run the second-tenant non-founder replay.
• Demonstrate a neutral export and first non-Microsoft restore.
• Compare Marketplace and direct procurement.
• Deliver the EU trust pack: architecture, DPA inputs, subprocessors/locations, retention, security, continuity and exit.
• Select the production commercial route explicitly.
• Do not enable production writes.

By day 180

Scale only if all gates pass:

• At least two independent paid outcomes using the same workflow.
• At least three buyers accept substantially the same price and scope.
• At least 30% cycle-time improvement without worse severe errors, review burden, reversals, accessibility or contestability.
• No core fork; second-tenant onboarding within the declared FDE budget.
• At least 65% contribution margin at P90 usage and fewer than four support hours per tenant-month.
• Zero cross-tenant findings in the declared test suite.
• Successful product-lockbox, restore, deletion and incident exercises.
• Dataheart beats the native substitute on material capability and implementation time or three-year cost.
• Marketplace demonstrates net procurement benefit.
• Non-Microsoft restore preserves meaning, policy and sampled receipts.

Otherwise narrow the workflow, change the cell boundary, keep Marketplace optional, operate as a specialist service or stop.

Panel evidence register

• P01 market/ecosystem — 01a03193-f44c-71c2-9dfa-f9b1bd5c7906
• P02 enterprise buying — 01a03193-f6a5-7f62-8e16-10f5f69720af
• P03 business/pricing — 01a03193-f93d-7831-b07c-80ada1b9eb44
• P04 Marketplace lifecycle — 01a03193-fc65-7593-9630-81b0b4eb8be5
• P05 security/regulation — 01a03193-ff6f-7cb2-9d68-ee22ae3d6fd8
• P06 technology/productivity — 01a03194-02de-7f52-8fcc-1284dceeda4c
• P07 portability/architecture — 01a03194-06b5-78a2-a750-b6175c9f7504
• P08 product/FDE — 01a03194-096d-7343-be93-1f0fb5fe51b1
• P09 prosocial/human consequences — 01a03194-0c92-7ed1-8e9a-7d958fe8d8a1
• P10 competitive red team — 01a03194-101a-7a31-977d-6908ca5cbde9
• P11 evidence-integrity audit — 01a031a1-6b01-7453-9867-a1a5ad174abe
• P12 commercial red team — 01a031a1-6d6d-7782-b546-d81877421d19
• P13 independent verification — 01a031a1-705b-7e80-9177-c1fbe4473d92

Repeated panel agreement was not treated as independent corroboration when panels reused the same Microsoft or EU source family.