Executive thesis

Evidence labels: Established practice = supported by standards/repeated research; Emerging practice = visible across several current programs but not yet mature; Hypothesis = a Dataheart design proposition requiring validation; Vendor claim = first-party assertion without an adequate public counterfactual.

The durable FDE moat is not embedded headcount, bespoke code, or switching friction. It is the rate at which Kugghuset can convert privileged field learning into:

• independently operable customer outcomes;
• reusable, multi-customer product primitives;
• portable deployment automation;
• regression tests, evaluations and operational evidence;
• a better understanding of recurring business problems.

The proposed flywheel is:

customer problem → production outcome → measured evidence → generalized pattern → core/pack promotion → faster next deployment

OpenAI publicly defines FDE success as production adoption, workflow impact and evaluation-driven feedback that changes product and model roadmaps. Palantir describes FDE as a field-to-core feedback mechanism; ServiceNow says its embedded engineers simultaneously solve customer problems and expand product capabilities. These establish convergence on the operating model, not causal proof that it produces superior economics. OpenAI, Palantir, ServiceNow 10-K.

For Dataheart:

• Customer ownership is a product constraint. Customer repositories, identities, keys, logs, runbooks, data and business definitions remain customer-controlled.
• Dual-profile parity is a forcing function. Anything promoted to core must pass equivalent behavioral, authorization and evidence tests in both Microsoft-native and self-hosted/open profiles.
• Field knowledge is not automatically company property. Only consented, sanitized abstractions, reusable code and non-customer-specific evaluations enter the shared corpus.
• The moat must survive an exit test. If retention depends on undocumented FDE knowledge or an unrehearsed migration, it is lock-in rather than product advantage.

I found no public controlled study comparing FDE and non-FDE delivery models, nor public FDE cohort margins, promote-to-core rates or lifetime maintenance costs. “FDE as moat” therefore remains a strong but testable hypothesis.

State of the art 2024–2026

Period	Status	Signal	Interpretation
2024	Established, correlational	DORA reported that internal-platform use was associated with higher individual productivity, team performance and delivery/operations performance, but also lower throughput and change stability. It stressed user-centeredness and developer independence.	An implementation factory can help, but a poorly designed platform merely centralizes friction.
2024	Established	NIST finalized SP 800-218A for secure development of generative-AI systems. The EU AI Act established lifecycle, logging, human-oversight and value-chain responsibilities.	FDE speed does not exempt field-built systems from controlled SDLC and regulatory role allocation.
2025	Emerging	OpenAI and Anthropic established explicit FDE organizations. OpenAI’s role spans discovery through rollout, adoption, evaluations and product feedback.	FDE is differentiating into engineering, deployment leadership, architecture and customer-success responsibilities rather than being a renamed solutions engineer.
2025	Established, correlational	DORA’s nearly 5,000-person study characterized AI as an amplifier: stronger throughput/product effects appeared in mature systems, while instability remained negatively associated with AI adoption.	AI-assisted FDE requires small batches, version control, automated checks, feedback and a quality internal platform.
2025	Vendor claim / emerging	Palantir released an “AI FDE” interface for operating Foundry through natural language.	Parts of implementation can be automated, but the high-judgment discovery, authority and accountability work remains unresolved.
2026	Emerging	ServiceNow’s 2025 10-K formally described Now Next AI engineers co-building with strategic customers while expanding product capability. OpenAI announced a Singapore FDE training program and more than 200 planned technical roles.	FDE is becoming an organizational capability and talent system, not only an elite individual role.
2026	Vendor claim / emerging	Rackspace reported about 400 Palantir certifications, including FDEs, and claimed a first joint deployment reduced quote-cycle time by 94%.	Certification and partner execution are becoming the scale-out mechanism, but the outcome claim lacks an independent counterfactual.
2026	Established regulatory change	Most of the EU AI Act became applicable on 2 August 2026. The EU Data Act had already applied since 12 September 2025.	Deployment contracts, provider/deployer classification, switching, exportability and responsibility for substantial modifications are now delivery-design issues.

Two contradictory automation findings matter:

• DORA’s 2024 study associated a 25% increase in AI adoption with 1.5% lower throughput and 7.2% lower stability; its 2025 study found a positive throughput relationship but continued instability. These are observational results, not causal estimates.
• METR’s early-2025 randomized study found 16 experienced open-source developers took 19% longer with AI. Its February 2026 update produced apparent speedups for some groups, but METR deemed the estimate unreliable because developers and AI-suitable tasks selected out of the control condition. DORA 2024, DORA 2025, METR 2025, METR 2026.

Load-bearing concepts

1. Outcome ownership, not output ownership

Established/emerging: The FDE owns discovery, technical scope, production delivery and adoption, but the customer owns the operational system and business decision.

Every engagement needs an outcome contract containing:

• affected workflow and accountable process owner;
• baseline, target and measurement method;
• eligible users/cases and adoption denominator;
• safety constraints and prohibited actions;
• production, handoff and exit acceptance criteria;
• provider/deployer responsibilities;
• explicit uncertainty and external dependencies.

A prototype, connector, dashboard or agent is evidence of work—not evidence of value.

2. Two coupled loops

Hypothesis: Dataheart should run two separately measured loops:

1. Customer loop: discover → build → deploy → adopt → measure → hand over.
2. Product loop: capture pattern → sanitize → generalize → test both profiles → promote → maintain or retire.

Combining them without explicit gates creates roadmap capture. Separating them completely creates consultancy that never improves the product.

3. Promote-to-core governance

Every field artifact should end in one of four destinations:

Destination	Required characteristics
Core primitive	General problem; stable interface; customer/IP hygiene complete; named owner; backward-compatibility plan; both deployment profiles conform.
Reusable domain pack	Repeats within a domain; versioned independently; documented prerequisites and support boundary; portable configuration rather than hidden code.
Customer-local extension	Truly customer-specific; owned in the customer repository; support cost explicit; expiry/review date; no silent dependency from core.
Retire/reject	No sustained adoption, no defensible outcome or maintenance cost exceeds demonstrated value.

Suggested promotion evidence—not an industry standard—is recurrence in multiple independent contexts, a demonstrated reduction in later delivery effort, and no regression in authorization, provenance or exit behavior.

4. Productized implementation factory

Established practice: A quality platform supplies self-service golden paths, clear feedback and secure repeatability. DORA also shows that platform initiatives can initially reduce delivery performance.

For Dataheart, the factory should generate and verify:

• customer-owned repositories and environment manifests;
• identity, policy and secret bindings;
• connectors and semantic mappings;
• evaluation and test packs;
• signed artifacts, dependency inventory and rollback metadata;
• monitoring, evidence and cost dashboards;
• upgrade, restore, handoff and exit runbooks.

The factory should remove plumbing while keeping the underlying declarative artifacts inspectable and editable.

5. Design-partner portfolio

Hypothesis: Select design partners for learning value as well as contract size:

priority ≈ business severity × executive ownership × data/access readiness × reuse potential × willingness to measure

A portfolio should include heterogeneous environments. If all design partners share the same cloud, industry or executive sponsor profile, “core” will encode a sample bias.

Customers should have an explicit veto over sharing proprietary context, but not over Kugghuset independently solving the same general problem elsewhere.

6. Delivery economics

Use a cohort contribution measure:

collected deployment fees + attributable subscription gross profit + expansion gross profit – fully loaded pod cost – compute/travel/support – maintenance reserve

Fully loaded cost includes bench time, presales, security onboarding, travel, customer-specific testing, core-team interruptions, aftercare and the dual-profile test matrix.

Record learning value separately:

later deployments × verified hours/cost avoided by promoted artifacts

Do not book speculative reuse as present margin.

Useful measures are:

• time to first accepted production outcome;
• eligible-workflow adoption and sustained use;
• outcome delta with baseline or counterfactual;
• change-failure rate and recovery time;
• reusable-core share versus local extension share;
• promotion yield and time to promotion;
• local exception inventory, age and upgrade lag;
• customer-independent operation rate;
• security/evidence conformance;
• cost-to-serve and contribution by cohort.

Lines of code, utilization, demo count and pilot count are dangerous primary measures.

Palantir’s 2025 filing illustrates why causal restraint matters: it reported an 82% company gross margin, while cost of revenue rose 39%, including an additional $29.1 million for field-service representatives. Neither number isolates FDE economics. Palantir 10-K.

7. Staffing and organizational learning

A practical initial pod hypothesis is:

• senior FDE/outcome lead;
• data and knowledge engineer;
• workflow/product or change specialist;
• part-time security/platform specialist;
• named customer product owner and domain authority.

Core product engineering, the implementation factory and the promotion council must remain distinct accountabilities. Avoid a lone “hero FDE” who simultaneously owns customer trust, production privileges, architecture approval and commercial escalation.

Staff by work in progress, risk and specialist bottlenecks—not a fixed accounts-per-FDE ratio. Rotate people between field and core, while retaining named long-term customer responsibility. Learning must survive rotation through decision records, reusable tests, taxonomy, incident reviews and recorded promotion decisions.

Reference patterns

Pattern A: Outcome pod with a core twin

Each customer pod has a named core-product counterpart. The pod owns delivery and adoption; the core twin owns generalization, compatibility and long-term product maintenance.

This creates a deliberate interface instead of relying on informal hallway feedback.

Pattern B: Thin customer overlay

Keep business vocabulary, mappings, rules, local integrations and approved extensions in a customer-owned overlay. Keep general engines, contracts and reusable adapters in core.

No customer-specific branch should be required to upgrade the platform. Temporary forks require an owner, cost reserve, expiry date and convergence plan.

Pattern C: Dual-profile implementation factory

A canonical capability contract is implemented twice:

Vendor-neutral invariant	Microsoft-native choice	Self-hosted/open choice
Customer-issued, least-privilege identities; no shared accounts	Entra ID, PIM, Conditional Access, managed identities	Standards-based OIDC/SAML, customer-operated identity/PAM, workload identities
Customer-owned version control and reproducible delivery	Azure Repos/Pipelines, ARM/Bicep, Azure Policy, ACR	Self-hosted Git, OpenTofu/Ansible/Helm, OCI registry, OPA-compatible policy
Customer-owned keys and secret lifecycle	Key Vault and native key management	Self-hosted secrets/key service or encrypted declarative secrets
Common correlation IDs, action evidence and exportable telemetry	Azure Monitor, Application Insights, Log Analytics, Purview where appropriate	OpenTelemetry-compatible collection and self-hosted metrics/logs/traces/catalog
Signed, versioned runtime artifact	Azure-native application, container or AKS packaging	OCI/Kubernetes, Podman or VM packaging appropriate to the environment
Identical business semantics, policy tests and action approvals	Microsoft adapters	Open-protocol/open-source adapters

These are example choices, not required brands. The invariant is the behavioral and evidentiary contract.

Pattern D: Design-partner cohort

Use several customers to test the same problem thesis. Pre-register which observations would cause the capability to be promoted, revised or abandoned. Maintain a “negative evidence” field so failed adoption and non-transferable requirements are not lost.

Pattern E: Graduated handoff

The delivery sequence should be:

FDE operates → customer shadows → customer operates with FDE approval → customer operates with FDE observation → customer operates independently

Production acceptance includes upgrade, rollback, incident, restore and access-revocation exercises—not only a feature demonstration.

Failure modes and counter-evidence

Failure mode	Consequence	Control
Bespoke-services trap	Revenue scales with scarce people; upgrades accumulate exceptions.	Explicit local-extension budget, maintenance reserve, promotion/retirement gate.
Strategic-customer roadmap capture	Highest-paying customer becomes the accidental product manager.	Portfolio evidence, core product owner, negative evidence, independent promotion council.
Hero FDE	Knowledge and privileges concentrate in one person.	Pod delivery, peer review, customer-owned documentation, rotation and handoff drills.
Shadow administration	FDEs acquire standing production privileges or bypass customer change control.	Customer-issued JIT access, session evidence, two-person action approval, immediate revocation.
Cross-customer contamination	Proprietary schemas, prompts, data or practices leak into core or another account.	Separate tenants/repos; sanitization and IP review; no raw field data in shared learning systems.
Agentic overreach	Automated implementation or remediation makes unauthorized changes.	Preview/dry-run, policy enforcement, scoped credentials, idempotency, kill switch and compensating action.
Fast code, slow system	AI creates review, testing and deployment bottlenecks.	Small batches; measure elapsed delivery, defects and stability rather than code-generation speed.
Platform bureaucracy	Golden paths become mandatory ticket queues.	Self-service, actionable feedback, escape hatch with time-bound waiver, platform product management.
Customer dependence	Customer cannot upgrade, diagnose or exit without Kugghuset.	Customer-owned artifacts, independence score, clean-room redeployment and exit tests.
Open-profile operational lock-in	Open source removes licence lock-in but adds specialist and upgrade dependence.	Supported bill of materials, reproducible bundles, offline upgrade path, customer training and alternative operators.
Microsoft-profile commercial lock-in	Native APIs, licensing and tenant architecture impede switching.	Canonical capability contract, export formats, adapter boundary and regularly exercised open-profile restore.
Regulatory role drift	FDE modification unexpectedly makes Kugghuset or the customer the AI-system provider.	Engagement-level provider/deployer matrix, change classification and legal/compliance gate.

Important counter-evidence:

• DORA’s platform findings were mixed: higher reported productivity coexisted with lower throughput and stability. Centralization and standardization are therefore not inherently beneficial.
• DORA and METR show that perceived AI productivity can diverge from end-to-end delivery performance.
• The Rackspace 94% cycle-time reduction is a vendor-reported single deployment, without disclosed baseline construction, confounders, sustainability or fully loaded cost.
• Palantir’s margins and growth cannot be attributed to FDE from public filings.
• The EU Data Act gives customers switching and export rights for covered data-processing services, but highly customer-specific services can be exempt from some switching obligations. Excessive customization can therefore create both operational and legal ambiguity. EU Data Act.
• Under AI Act Article 25, a deployer or third party can become the provider of a high-risk system by putting its name on it, substantially modifying it or changing its intended purpose into a high-risk use. Contracts alone cannot erase the operational facts. EU AI Act.

Implications for Dataheart

1. Define FDE as a product function. Its charter should include discovery, delivery, adoption, controlled action, handoff and field-to-core learning. It should not become unbounded professional services.

2. Make customer ownership auditable. Repositories, tenant administration, production identities, keys, logs, domain semantics, configurations and exportable data must be controlled by the customer. Kugghuset access should be revocable without loss of operation.

3. Treat portability as release conformance. “Supports two profiles” is insufficient. The same workflow contract, authorization decisions, evidence records and evaluations must pass in both profiles.

4. Create a field-artifact registry. Every extension records customer owner, Kugghuset owner, IP class, data classification, destination, support tier, maintenance reserve, profile coverage and expiry date.

5. Establish a promotion council. Product, core engineering, FDE, security and customer-success representatives decide core/pack/local/retire. Sales alone cannot approve core inclusion.

6. Separate learning from customer data. The organizational corpus should contain abstract problem signatures, de-identified failure taxonomies, evaluation cases, decision records and reusable implementation patterns—not copied customer documents or production traces.

7. Price exceptions explicitly. Standard deployment, reusable domain packs and local engineering should be distinguishable commercially. Hidden “free implementation” makes product economics impossible to see.

8. Reward customer independence. FDE performance should include adoption, evidenced outcomes, portability, reusable promotion and successful handoff—not only expansion or utilization.

9. Use partners only after repeatability exists. Certification can scale a factory; it cannot compensate for undocumented architecture. Partners should pass clean-room delivery and evidence tests before representing Dataheart.

10. Keep trust as the moat. Customer-owned deployment and rehearsed exit may reduce coercive retention, but should increase access to real workflows, referenceability and long-term co-development. That is the moat hypothesis worth testing.

Connections to other domains

• Lean manufacturing: FDE resembles frontline kaizen: learning occurs where work happens. Promote-to-core governance prevents local optimization from becoming global complexity.
• Franchise systems: Core methods and quality controls are standardized while local operators adapt to context. Certification works only when the operating system is teachable.
• Compilers: Customer requirements should compile into two deployment targets from one semantic, authorization and evidence model. Profile-specific code is an adapter, not business truth.
• SRE: Error budgets, small batches and rollback discipline prevent delivery speed from consuming reliability.
• Causal inference: Workflow impact needs baselines, comparison groups or staged rollout. Before/after anecdotes systematically over-credit the intervention.
• Knowledge management: Tacit field knowledge compounds only when transformed into searchable artifacts, tests, taxonomies and decisions with provenance.
• Regulated product engineering: FDEs operate along the provider–deployer boundary; design changes can change legal roles and assurance duties.

Recommended experiments and conformance tests

1. Dual-profile clean-room build

   Give two teams only the canonical artifacts. One deploys Microsoft-native; the other deploys self-hosted/open. Pass if both satisfy the same workflow, policy, evidence and rollback tests without undocumented FDE knowledge.

2. Customer-independence test

   After handoff, require the customer team to upgrade, roll back, diagnose an incident, rotate credentials and restore from backup without standing Kugghuset access.

3. Exit and functional-equivalence drill

   Export customer data, metadata, configurations, semantic definitions, policies and evidence; restore the agreed minimum workflow in the alternate profile. Measure elapsed time, loss, manual intervention and hidden dependencies.

4. Promote-to-core trial

   Track a candidate pattern from one engagement into at least two independent contexts. Compare delivery time, defects and customization before and after promotion. Reject promotion if reuse merely relocates account-specific complexity.

5. AI-assisted FDE randomized trial

   Randomize comparable factory tasks between human-only and AI-assisted execution. Measure total elapsed time, reviewer time, escaped defects, stability, evidence completeness and customer acceptance—not generated code volume.

6. Compromised-FDE drill

   Simulate loss of an FDE identity. Pass if it cannot reach other customers, cannot perform unapproved high-impact actions, and can be revoked without service interruption.

7. Field-to-core contamination test

   Seed customer-specific identifiers and confidential constructs in a test engagement. Verify that sanitization and promotion controls prevent them entering shared repositories, prompts, telemetry or evaluation corpora.

8. Economics cohort test

   Compare standard-factory, reusable-pack and bespoke-extension cohorts using fully loaded contribution, maintenance reserve, time to outcome, adoption and expansion. Do not merge the cohorts into one gross-margin figure.

9. Partner replication test

   A trained external team delivers from the factory and documentation without direct help from the original FDE. Measure escalations, deviations, security findings and outcome quality.

10. Roadmap-capture audit

    Quarterly, compare core roadmap items with recurring evidence across accounts. Flag items driven by one customer, one seller or one deployment profile unless explicitly funded and isolated.

Sources

1. OpenAI — Forward Deployed Engineer role — accessed 2026-08-23; first-party role specification.
2. Palantir Architecture Center — FDE as field-to-core development — current 2026, accessed 2026-08-23; vendor description.
3. Anthropic careers — FDE, FDE management and technical deployment roles — accessed 2026-08-23; first-party organizational signal.
4. ServiceNow 2025 Form 10-K — filed 2026-01-29; primary regulatory filing.
5. OpenAI for Singapore — 2026-05-19; first-party FDE scaling and training announcement.
6. Palantir — AI FDE beta announcement — 2025-11-18; vendor product announcement.
7. Rackspace/Palantir partnership update, SEC exhibit — 2026-07-09; first-party claims filed with the SEC.
8. Palantir 2025 Form 10-K — filed 2026-02-17; primary financial and risk evidence.
9. DORA — 2024 Accelerate State of DevOps Report — 2024-10-22; primary industry research.
10. DORA — 2025 State of AI-Assisted Software Development — 2025-09-23; primary industry research.
11. METR — Early-2025 developer productivity randomized trial — 2025-07-10; primary experimental research.
12. METR — Updated experiment-design and selection-bias analysis — 2026-02-24; primary research update.
13. NIST SP 800-218A — 2024-07-26; finalized secure-development guidance.
14. Regulation (EU) 2024/1689 — AI Act — Official Journal 2024-07-12; generally applicable from 2026-08-02.
15. Regulation (EU) 2023/2854 — Data Act — adopted 2023-12-13; applicable from 2025-09-12.

Resonansia graph payload

{
  "entities": [
    {
      "id": "dataheart:fde-operating-model",
      "type": "operating-model",
      "name": "Forward deployed engineering",
      "description": "End-to-end customer discovery, production delivery, adoption, handoff and field-to-core learning.",
      "status": "emerging",
      "valid_as_of": "2026-08-23",
      "tags": ["fde", "delivery", "product-learning"],
      "source_urls": [
        "https://openai.com/careers/forward-deployed-engineer-%28fde%29-sf-san-francisco/",
        "https://www.palantir.com/docs/foundry/architecture-center/overview",
        "https://www.sec.gov/Archives/edgar/data/1373715/000137371526000007/now-20251231.htm"
      ]
    },
    {
      "id": "dataheart:customer-outcome-contract",
      "type": "governance-artifact",
      "name": "Customer outcome contract",
      "description": "Versioned definition of workflow, baseline, target, adoption denominator, constraints, responsibilities and acceptance criteria.",
      "status": "recommended",
      "valid_as_of": "2026-08-23",
      "tags": ["outcomes", "measurement", "accountability"],
      "source_urls": [
        "https://openai.com/careers/forward-deployed-engineer-%28fde%29-sf-san-francisco/",
        "https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report"
      ]
    },
    {
      "id": "dataheart:design-partner-loop",
      "type": "product-development-loop",
      "name": "Design partner loop",
      "description": "Structured co-development loop that validates a problem, production behavior, adoption and transferable learning.",
      "status": "emerging",
      "valid_as_of": "2026-08-23",
      "tags": ["design-partner", "co-development", "learning"],
      "source_urls": [
        "https://openai.com/careers/forward-deployed-engineer-%28fde%29-sf-san-francisco/",
        "https://www.sec.gov/Archives/edgar/data/1373715/000137371526000007/now-20251231.htm"
      ]
    },
    {
      "id": "dataheart:implementation-factory",
      "type": "delivery-platform",
      "name": "Implementation factory",
      "description": "Self-service golden paths producing reproducible deployments, tests, evidence, rollback and handoff artifacts.",
      "status": "recommended",
      "valid_as_of": "2026-08-23",
      "tags": ["platform-engineering", "automation", "repeatability"],
      "source_urls": [
        "https://dora.dev/research/2024/dora-report/2024-dora-accelerate-state-of-devops-report.pdf",
        "https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report",
        "https://www.nist.gov/publications/secure-software-development-practices-generative-ai-and-dual-use-foundation-models-ssdf"
      ]
    },
    {
      "id": "dataheart:promote-to-core-gate",
      "type": "product-governance",
      "name": "Promote-to-core gate",
      "description": "Evidence-based classification of field artifacts as core, reusable pack, customer-local extension or retired work.",
      "status": "hypothesis",
      "valid_as_of": "2026-08-23",
      "tags": ["product-governance", "reuse", "maintenance"],
      "source_urls": [
        "https://www.palantir.com/docs/foundry/architecture-center/overview",
        "https://openai.com/careers/forward-deployed-engineer-%28fde%29-sf-san-francisco/"
      ]
    },
    {
      "id": "dataheart:customer-owned-deployment",
      "type": "architectural-invariant",
      "name": "Customer-owned deployment",
      "description": "Customer control of repositories, tenant administration, production identities, keys, evidence, data and operational runbooks.",
      "status": "recommended",
      "valid_as_of": "2026-08-23",
      "tags": ["customer-ownership", "portability", "trust"],
      "source_urls": [
        "https://eur-lex.europa.eu/eli/reg/2023/2854"
      ]
    },
    {
      "id": "dataheart:portable-conformance-contract",
      "type": "architectural-invariant",
      "name": "Portable conformance contract",
      "description": "Common behavioral, semantic, authorization, evidence and lifecycle tests shared by both deployment profiles.",
      "status": "recommended",
      "valid_as_of": "2026-08-23",
      "tags": ["conformance", "portability", "dual-profile"],
      "source_urls": [
        "https://eur-lex.europa.eu/eli/reg/2023/2854",
        "https://www.nist.gov/publications/secure-software-development-practices-generative-ai-and-dual-use-foundation-models-ssdf"
      ]
    },
    {
      "id": "dataheart:microsoft-native-profile",
      "type": "deployment-profile",
      "name": "Microsoft-native deployment profile",
      "description": "Deployment using Microsoft-native identity, policy, delivery, observability and runtime services while conforming to common Dataheart behavior.",
      "status": "required",
      "valid_as_of": "2026-08-23",
      "tags": ["microsoft", "azure", "deployment"],
      "source_urls": []
    },
    {
      "id": "dataheart:self-hosted-open-profile",
      "type": "deployment-profile",
      "name": "Self-hosted open deployment profile",
      "description": "Customer-operated deployment using open protocols and self-hostable components while conforming to common Dataheart behavior.",
      "status": "required",
      "valid_as_of": "2026-08-23",
      "tags": ["self-hosted", "open", "deployment"],
      "source_urls": [
        "https://eur-lex.europa.eu/eli/reg/2023/2854"
      ]
    },
    {
      "id": "dataheart:organizational-learning-corpus",
      "type": "knowledge-asset",
      "name": "Organizational learning corpus",
      "description": "Sanitized problem signatures, evaluation cases, failure taxonomies, decision records and reusable implementation patterns.",
      "status": "hypothesis",
      "valid_as_of": "2026-08-23",
      "tags": ["learning", "knowledge", "moat"],
      "source_urls": [
        "https://www.palantir.com/docs/foundry/architecture-center/overview",
        "https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report"
      ]
    },
    {
      "id": "dataheart:delivery-economics-ledger",
      "type": "measurement-system",
      "name": "Delivery economics ledger",
      "description": "Cohort-level accounting of fees, attributable gross profit, pod cost, support, compute, maintenance reserve and verified reuse savings.",
      "status": "recommended",
      "valid_as_of": "2026-08-23",
      "tags": ["economics", "cost-to-serve", "margin"],
      "source_urls": [
        "https://www.sec.gov/Archives/edgar/data/1321655/000132165526000011/pltr-20251231.htm"
      ]
    },
    {
      "id": "dataheart:least-privilege-field-access",
      "type": "security-control",
      "name": "Least-privilege field access",
      "description": "Customer-issued, just-in-time and auditable access for FDEs with rapid revocation and no cross-customer reach.",
      "status": "established",
      "valid_as_of": "2026-08-23",
      "tags": ["security", "identity", "fde-access"],
      "source_urls": [
        "https://www.nist.gov/publications/secure-software-development-practices-generative-ai-and-dual-use-foundation-models-ssdf"
      ]
    },
    {
      "id": "dataheart:ai-assisted-delivery",
      "type": "automation-capability",
      "name": "AI-assisted delivery",
      "description": "Use of coding and agentic systems to accelerate implementation, testing, documentation and platform operation under controlled review.",
      "status": "emerging",
      "valid_as_of": "2026-08-23",
      "tags": ["ai", "automation", "developer-productivity"],
      "source_urls": [
        "https://www.palantir.com/docs/foundry/announcements/2025-11",
        "https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/",
        "https://metr.org/blog/2026-02-24-uplift-update/"
      ]
    },
    {
      "id": "dataheart:regulatory-role-allocation",
      "type": "governance-control",
      "name": "Regulatory role allocation",
      "description": "Engagement-level classification of provider, deployer and third-party responsibilities, including substantial modifications.",
      "status": "established",
      "valid_as_of": "2026-08-23",
      "tags": ["eu-ai-act", "provider", "deployer"],
      "source_urls": [
        "https://eur-lex.europa.eu/eli/reg/2024/1689/oj?locale=en"
      ]
    }
  ],
  "relations": [
    {
      "id": "dataheart:relation-fde-delivers-outcome",
      "from": "dataheart:fde-operating-model",
      "predicate": "delivers",
      "to": "dataheart:customer-outcome-contract",
      "description": "The FDE pod is accountable for production adoption and evidenced workflow impact.",
      "confidence": 0.93,
      "status": "emerging",
      "valid_as_of": "2026-08-23",
      "source_urls": [
        "https://openai.com/careers/forward-deployed-engineer-%28fde%29-sf-san-francisco/"
      ]
    },
    {
      "id": "dataheart:relation-design-partner-generates-learning",
      "from": "dataheart:design-partner-loop",
      "predicate": "generates",
      "to": "dataheart:organizational-learning-corpus",
      "description": "Measured field experience produces sanitized reusable knowledge.",
      "confidence": 0.82,
      "status": "hypothesis",
      "valid_as_of": "2026-08-23",
      "source_urls": [
        "https://www.palantir.com/docs/foundry/architecture-center/overview",
        "https://www.sec.gov/Archives/edgar/data/1373715/000137371526000007/now-20251231.htm"
      ]
    },
    {
      "id": "dataheart:relation-learning-feeds-promotion",
      "from": "dataheart:organizational-learning-corpus",
      "predicate": "feeds",
      "to": "dataheart:promote-to-core-gate",
      "description": "Reusable evidence supports promotion, quarantine or retirement decisions.",
      "confidence": 0.86,
      "status": "hypothesis",
      "valid_as_of": "2026-08-23",
      "source_urls": []
    },
    {
      "id": "dataheart:relation-factory-enforces-conformance",
      "from": "dataheart:implementation-factory",
      "predicate": "enforces",
      "to": "dataheart:portable-conformance-contract",
      "description": "The factory generates deployments and verifies shared behavior across profiles.",
      "confidence": 0.91,
      "status": "recommended",
      "valid_as_of": "2026-08-23",
      "source_urls": [
        "https://dora.dev/research/2024/dora-report/2024-dora-accelerate-state-of-devops-report.pdf",
        "https://www.nist.gov/publications/secure-software-development-practices-generative-ai-and-dual-use-foundation-models-ssdf"
      ]
    },
    {
      "id": "dataheart:relation-microsoft-conforms",
      "from": "dataheart:microsoft-native-profile",
      "predicate": "conforms-to",
      "to": "dataheart:portable-conformance-contract",
      "description": "The Microsoft-native implementation must satisfy the common behavioral and evidence contract.",
      "confidence": 0.98,
      "status": "required",
      "valid_as_of": "2026-08-23",
      "source_urls": []
    },
    {
      "id": "dataheart:relation-open-conforms",
      "from": "dataheart:self-hosted-open-profile",
      "predicate": "conforms-to",
      "to": "dataheart:portable-conformance-contract",
      "description": "The self-hosted/open implementation must satisfy the common behavioral and evidence contract.",
      "confidence": 0.98,
      "status": "required",
      "valid_as_of": "2026-08-23",
      "source_urls": []
    },
    {
      "id": "dataheart:relation-customer-ownership-constrains-fde",
      "from": "dataheart:customer-owned-deployment",
      "predicate": "constrains",
      "to": "dataheart:fde-operating-model",
      "description": "Field delivery must leave an independently operable and exportable customer system.",
      "confidence": 0.94,
      "status": "recommended",
      "valid_as_of": "2026-08-23",
      "source_urls": [
        "https://eur-lex.europa.eu/eli/reg/2023/2854"
      ]
    },
    {
      "id": "dataheart:relation-access-protects-deployment",
      "from": "dataheart:least-privilege-field-access",
      "predicate": "protects",
      "to": "dataheart:customer-owned-deployment",
      "description": "Revocable customer-issued access reduces shadow administration and compromise blast radius.",
      "confidence": 0.95,
      "status": "established",
      "valid_as_of": "2026-08-23",
      "source_urls": [
        "https://www.nist.gov/publications/secure-software-development-practices-generative-ai-and-dual-use-foundation-models-ssdf"
      ]
    },
    {
      "id": "dataheart:relation-ai-accelerates-factory",
      "from": "dataheart:ai-assisted-delivery",
      "predicate": "may-accelerate",
      "to": "dataheart:implementation-factory",
      "description": "AI may reduce implementation effort when surrounding review, testing and delivery systems are mature.",
      "confidence": 0.64,
      "status": "emerging",
      "valid_as_of": "2026-08-23",
      "source_urls": [
        "https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report",
        "https://metr.org/blog/2026-02-24-uplift-update/"
      ]
    },
    {
      "id": "dataheart:relation-economics-measures-fde",
      "from": "dataheart:delivery-economics-ledger",
      "predicate": "measures",
      "to": "dataheart:fde-operating-model",
      "description": "The ledger distinguishes repeatable product economics from hidden bespoke-services cost.",
      "confidence": 0.9,
      "status": "recommended",
      "valid_as_of": "2026-08-23",
      "source_urls": [
        "https://www.sec.gov/Archives/edgar/data/1321655/000132165526000011/pltr-20251231.htm"
      ]
    },
    {
      "id": "dataheart:relation-role-allocation-governs-fde",
      "from": "dataheart:regulatory-role-allocation",
      "predicate": "governs",
      "to": "dataheart:fde-operating-model",
      "description": "Field changes must be evaluated for provider, deployer and substantial-modification consequences.",
      "confidence": 0.97,
      "status": "established",
      "valid_as_of": "2026-08-23",
      "source_urls": [
        "https://eur-lex.europa.eu/eli/reg/2024/1689/oj?locale=en"
      ]
    },
    {
      "id": "dataheart:relation-promotion-reduces-future-cost",
      "from": "dataheart:promote-to-core-gate",
      "predicate": "should-reduce",
      "to": "dataheart:delivery-economics-ledger",
      "description": "Successful promotion should appear as verified lower effort and maintenance cost in later cohorts.",
      "confidence": 0.8,
      "status": "hypothesis",
      "valid_as_of": "2026-08-23",
      "source_urls": []
    }
  ],
  "claims": [
    {
      "id": "dataheart:claim-fde-convergence",
      "statement": "FDE is converging into an end-to-end product discovery, production delivery, adoption and field-to-core learning model.",
      "confidence": 0.9,
      "evidence_for": [
        "OpenAI assigns discovery through rollout, adoption, workflow impact and product feedback to FDEs.",
        "Palantir describes FDE as a direct field-to-core product-development mechanism.",
        "ServiceNow reports embedded engineers co-building customer solutions while expanding product capabilities."
      ],
      "evidence_against": [
        "Public role definitions do not demonstrate delivery quality or economics.",
        "The title is not standardized and may conceal materially different responsibilities."
      ],
      "implications": "Dataheart should define the role through accountabilities and measurable gates rather than the FDE title.",
      "valid_as_of": "2026-08-23",
      "source_urls": [
        "https://openai.com/careers/forward-deployed-engineer-%28fde%29-sf-san-francisco/",
        "https://www.palantir.com/docs/foundry/architecture-center/overview",
        "https://www.sec.gov/Archives/edgar/data/1373715/000137371526000007/now-20251231.htm"
      ]
    },
    {
      "id": "dataheart:claim-fde-moat-hypothesis",
      "statement": "FDE becomes a durable moat only when field learning compounds into reusable product assets while customer operation remains independent.",
      "confidence": 0.75,
      "evidence_for": [
        "Several vendors explicitly link embedded delivery to core product learning.",
        "Reusable automation can reduce future delivery effort and improve consistency."
      ],
      "evidence_against": [
        "No public controlled comparison isolates FDE as the cause of superior retention, growth or margin.",
        "Bespoke delivery can increase personnel cost, roadmap capture and maintenance entropy."
      ],
      "implications": "Measure promotion yield, verified reuse savings, portability and customer independence; do not count switching friction as moat.",
      "valid_as_of": "2026-08-23",
      "source_urls": [
        "https://www.palantir.com/docs/foundry/architecture-center/overview",
        "https://www.sec.gov/Archives/edgar/data/1321655/000132165526000011/pltr-20251231.htm"
      ]
    },
    {
      "id": "dataheart:claim-platform-factory-mixed-effects",
      "statement": "An implementation platform can improve productivity and consistency but may reduce throughput and stability when it is immature or not user-centered.",
      "confidence": 0.91,
      "evidence_for": [
        "DORA 2024 associated internal-platform use with productivity and team-performance improvements."
      ],
      "evidence_against": [
        "The same DORA analysis associated platform use with lower throughput and change stability.",
        "The findings are observational and do not establish causality."
      ],
      "implications": "Treat the implementation factory as a product, begin with a narrow golden path and measure system-level delivery outcomes.",
      "valid_as_of": "2026-08-23",
      "source_urls": [
        "https://dora.dev/research/2024/dora-report/2024-dora-accelerate-state-of-devops-report.pdf"
      ]
    },
    {
      "id": "dataheart:claim-ai-leverage-uncertain",
      "statement": "AI-assisted FDE can create leverage, but local code-generation speed is not a reliable proxy for end-to-end delivery improvement.",
      "confidence": 0.93,
      "evidence_for": [
        "DORA 2025 found positive throughput relationships in stronger organizational systems.",
        "METR's later study produced signals consistent with speedup for some selected participants."
      ],
      "evidence_against": [
        "DORA continued to observe a negative stability relationship.",
        "METR's early-2025 randomized trial found a 19 percent slowdown.",
        "METR judged its later central estimate unreliable because of selection and measurement effects."
      ],
      "implications": "Randomize matched delivery tasks and measure elapsed time, review cost, defects, stability and accepted customer outcome.",
      "valid_as_of": "2026-08-23",
      "source_urls": [
        "https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report",
        "https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/",
        "https://metr.org/blog/2026-02-24-uplift-update/"
      ]
    },
    {
      "id": "dataheart:claim-customer-ownership",
      "statement": "Customer-owned artifacts, exportability and rehearsed switching should be Dataheart product acceptance criteria.",
      "confidence": 0.94,
      "evidence_for": [
        "The EU Data Act establishes contractual, technical and assistance duties for switching covered data-processing services.",
        "Customer ownership reduces dependency on undocumented FDE knowledge."
      ],
      "evidence_against": [
        "Functional equivalence can be limited to shared features.",
        "Highly customer-specific services may be exempt from some switching obligations.",
        "Open-source components can still create operational skill lock-in."
      ],
      "implications": "Run clean-room deployment, alternate-profile restore and customer-independent operation tests.",
      "valid_as_of": "2026-08-23",
      "source_urls": [
        "https://eur-lex.europa.eu/eli/reg/2023/2854"
      ]
    },
    {
      "id": "dataheart:claim-dual-profile-gate",
      "statement": "Promotion to core should require identical behavioral, authorization and evidence conformance across Microsoft-native and self-hosted/open profiles.",
      "confidence": 0.87,
      "evidence_for": [
        "A common contract prevents deployment-specific implementation details from becoming business semantics.",
        "Dual implementation exposes hidden dependencies and improves switching evidence."
      ],
      "evidence_against": [
        "Maintaining two implementations increases testing, support and release cost.",
        "Strict lowest-common-denominator design could suppress useful native capabilities."
      ],
      "implications": "Keep profile-specific optimizations behind adapters and allow extensions only when shared semantics and evidence remain intact.",
      "valid_as_of": "2026-08-23",
      "source_urls": [
        "https://eur-lex.europa.eu/eli/reg/2023/2854",
        "https://www.nist.gov/publications/secure-software-development-practices-generative-ai-and-dual-use-foundation-models-ssdf"
      ]
    },
    {
      "id": "dataheart:claim-regulatory-role-drift",
      "statement": "Field customization can change a party's regulatory role when it rebrands or substantially modifies a high-risk AI system or changes its intended purpose.",
      "confidence": 0.99,
      "evidence_for": [
        "EU AI Act Article 25 explicitly defines circumstances in which a deployer or third party becomes the provider."
      ],
      "evidence_against": [
        "Applicability depends on system classification, intended purpose, facts of the modification and transitional provisions."
      ],
      "implications": "Classify provider and deployer responsibilities at engagement start and re-evaluate every material field change.",
      "valid_as_of": "2026-08-23",
      "source_urls": [
        "https://eur-lex.europa.eu/eli/reg/2024/1689/oj?locale=en"
      ]
    },
    {
      "id": "dataheart:claim-partner-scaling",
      "statement": "Partner certification can scale FDE capacity only after delivery artifacts and conformance tests are sufficiently productized.",
      "confidence": 0.78,
      "evidence_for": [
        "Rackspace reported a large cohort of Palantir-certified FDEs and an initial customer deployment.",
        "OpenAI announced an FDE training program as part of geographic scaling."
      ],
      "evidence_against": [
        "Certification counts do not demonstrate independent production quality.",
        "The reported customer outcome is a vendor claim without disclosed counterfactual or delivery cost."
      ],
      "implications": "Require clean-room delivery, security and handoff tests before a partner can deliver Dataheart independently.",
      "valid_as_of": "2026-08-23",
      "source_urls": [
        "https://www.sec.gov/Archives/edgar/data/1810019/000181001926000078/ex991-pressrelease.htm",
        "https://openai.com/index/introducing-openai-for-singapore/"
      ]
    }
  ]
}