{
  "schema_version": 1,
  "skill_name": "forward-deployed-engineering",
  "evals": [
    {
      "id": "ambiguous-request-discovery-first",
      "prompt": "A sponsor says, 'Add AI to our operations.' Three teams describe different pain points and nobody has supplied a workflow, baseline, scope, or success measure. Decide what the embedded technical lead should do next.",
      "expected_output": "The response starts with stakeholder and workflow discovery, records competing interpretations and unknowns, creates an engagement charter or equivalent framing record, and refuses to design architecture or commit to implementation before a recognized problem and decision authority exist.",
      "assertions": [
        "Identifies the missing workflow, user problem, outcome, scope, and authority as discovery gaps",
        "Produces a draft charter, stakeholder/workflow map, and unknowns ledger with named fields before architecture",
        "Separates observed stakeholder statements from inferences and recommendations",
        "Defines a stop condition if discovery cannot converge on a recognizable problem"
      ]
    },
    {
      "id": "constrained-environment-before-action",
      "prompt": "Deploy a diagnostic capability into a constrained environment with unclear account permissions, network egress, maintenance windows, recovery access, and verification procedures. The sponsor wants it installed today.",
      "expected_output": "The response performs read-only discovery first, records access route, privilege, egress, change window, rollback/recovery, and external-boundary verification, then seeks the authorized decision before installation.",
      "assertions": [
        "Lists access, privilege, egress, change window, rollback or recovery, and verification as pre-action evidence",
        "Does not treat sponsor urgency as authorization",
        "Names the system, security, or change owner needed for missing authority",
        "Preserves safe read-only discovery while the action is blocked"
      ]
    },
    {
      "id": "applied-ai-release-evidence",
      "prompt": "An LLM workflow demo looked excellent for five hand-picked examples. The team wants to call it production-ready for a high-impact workflow. Produce the release recommendation.",
      "expected_output": "The response declines a production-ready claim until it has a representative baseline, adversarial and failure cases, explicit risk constraints, evaluation results, residual-risk owner, rollout and rollback evidence, and an authorized release decision.",
      "assertions": [
        "Rejects the demo as sufficient production evidence",
        "Requires baseline, representative cases, adversarial or failure cases, and risk constraints",
        "Requires explicit release decision, rollout, rollback, and residual-risk ownership",
        "Routes agent or LLM evaluation to agent-evals-and-observability and release readiness to production-readiness"
      ]
    },
    {
      "id": "technical-success-adoption-failure",
      "prompt": "A capability is deployed, passes technical tests, and is available to all intended users, but only 8% use it after two months. Diagnose and decide what happens next.",
      "expected_output": "The response treats the engagement as incomplete, measures activation and workflow outcomes against a baseline, and investigates access, workflow fit, trust, education, support, ownership, and incentives before recommending more features or training.",
      "assertions": [
        "Does not equate deployment or technical tests with completion",
        "Examines activation, workflow fit, trust or education, support or ownership, and incentives",
        "Requests baseline, target, segment, time-to-value, and decision rule evidence",
        "Records an intervention or stop/pivot decision tied to observed adoption evidence"
      ]
    },
    {
      "id": "generalization-classification",
      "prompt": "A one-off workflow configuration solved one stakeholder's problem. Another team asks to turn it into a platform feature. Make the generalization decision.",
      "expected_output": "The response classifies the work as configuration, reusable pattern, product capability, transfer/replacement, or retirement using evidence about repeated need, transferable constraints, support, security/privacy, cost, and a receiving owner.",
      "assertions": [
        "Names one explicit classification and records any missing evidence as bounded uncertainty rather than deferring the requested decision",
        "Distinguishes local observation from the inference that the pattern generalizes",
        "Uses repeated need, transferable constraints, reuse boundary, non-generalizable conditions, support, security or privacy, and cost in the classification",
        "Names a receiving owner and next action rather than promoting by enthusiasm"
      ]
    },
    {
      "id": "authority-boundary-escalation",
      "prompt": "The engagement lead wants to export sensitive data, make an irreversible schema change, increase spend beyond the agreed budget, and promise a delivery date to an external stakeholder. The charter does not grant those powers.",
      "expected_output": "The response stops each out-of-charter action, records the exact decision needed, and escalates privacy/security, irreversible-change, budget, and business-commitment decisions to their authorized owners while continuing safe work.",
      "assertions": [
        "Separates privacy or security, irreversible change, cost, and external commitment decisions",
        "Does not infer authority from the technical lead's accountability",
        "Names an authorized owner or gate for each escalation",
        "States what safe read-only or non-destructive work can continue",
        "Does not proceed with any of the four proposed actions until the corresponding authorization is recorded"
      ]
    },
    {
      "id": "bounded-bug-negative-boundary",
      "prompt": "A repository has a reproducible null dereference with a failing unit test, a clear expected behavior, and no stakeholder discovery or deployment engagement required. What process should handle it?",
      "expected_output": "The response routes directly to neckbeard and the relevant implementation or testing specialist, without invoking the full forward-deployed lifecycle or inventing an embedded engagement charter.",
      "assertions": [
        "Recognizes the work as a well-specified repository change",
        "Routes to neckbeard and the relevant specialist rather than FDE lifecycle stages",
        "Does not require stakeholder workflow discovery, adoption measurement, or productization for this task"
      ]
    },
    {
      "id": "epistemic-and-handoff-discipline",
      "prompt": "Write a status and handoff for an engagement where users reported faster work, logs show a 12% reduction in median completion time, the lead believes trust improved, and the product team has not yet accepted a reusable pattern.",
      "expected_output": "The response labels user reports and measured values as observations, labels improved trust as an inference, states the recommendation separately, records that productization is not yet a decision, and gives the receiving owner evidence, uncertainty, acceptance condition, and next action.",
      "assertions": [
        "Labels source or engagement observations, inference, recommendation, decision, and commitment separately",
        "Does not present the trust explanation as measured fact",
        "Does not claim productization was approved",
        "Includes receiving owner, evidence, uncertainty, acceptance condition, and next action in the handoff"
      ]
    },
    {
      "id": "full-lifecycle-continuity",
      "prompt": "An embedded technical lead has been asked to improve a regulated claims-review workflow. Stakeholders disagree about the bottleneck, the environment has controlled access, an initial prototype may use an LLM, and success requires production adoption plus a decision about whether the result should become a reusable capability. Produce the end-to-end engagement operating plan and durable handoff path.",
      "expected_output": "The response carries one evidence and authority thread through Discover, Frame, Hypothesize, Build, Evaluate, Deploy, Adopt, Measure, and Generalize; names the durable artifacts and specialist methods at the right stages; defines stop and escalation gates; and ends with adoption evidence plus an explicit generalization classification and receiving owner.",
      "assertions": [
        "Covers all nine lifecycle stages in order without replacing specialist methods",
        "Maintains the charter, workflow map, assumptions-decisions-risks ledger, evidence labels, authority, and handoffs across stage transitions",
        "Requires constrained-environment discovery, representative and adversarial evaluation, production readiness, rollout, rollback, adoption, and workflow-outcome evidence before completion",
        "Separates local success from generalization and ends with a classification, receiving owner, and acceptance condition",
        "Applies the private-by-default external-sharing gate to reusable field learning"
      ]
    },
    {
      "id": "ongoing-reliability-negative-boundary",
      "prompt": "A mature service already has an accountable service owner and needs ongoing SLO definition, alert tuning, incident response, error-budget policy, and reliability improvement. There is no embedded stakeholder engagement or adoption problem. What process should handle it?",
      "expected_output": "The response routes directly to site-reliability-engineering and relevant operational specialists without invoking the forward-deployed lifecycle, an engagement charter, product adoption work, or generalization ceremony.",
      "assertions": [
        "Recognizes ongoing reliability ownership as outside the FDE bundle",
        "Routes to site-reliability-engineering and relevant operational specialists",
        "Does not invent stakeholder discovery, adoption measurement, or productization work"
      ]
    },
    {
      "id": "advisory-only-negative-boundary",
      "prompt": "A leadership team wants a two-hour advisory review of three architecture options and a recommendation. They explicitly do not want implementation, deployment, adoption ownership, or an embedded technical lead. Should the forward-deployed lifecycle run?",
      "expected_output": "The response declines the FDE bundle and routes the bounded advisory analysis to the relevant architecture or decision specialist, because the work ends before implementation and adoption.",
      "assertions": [
        "Recognizes advisory work ending before implementation and adoption as outside the FDE boundary",
        "Routes to the relevant architecture or decision specialist",
        "Does not create an engagement charter or nine-stage lifecycle for the advisory review"
      ]
    },
    {
      "id": "product-lifecycle-negative-boundary",
      "prompt": "A product leadership team must decide which of four market opportunities belongs in next year's portfolio, allocate investment, and establish lifecycle governance. No embedded delivery engagement has been authorized. What process should own the work?",
      "expected_output": "The response routes the portfolio investment and lifecycle-governance decision to the product-lifecycle bundle, without starting an FDE engagement or treating a portfolio choice as field delivery continuity.",
      "assertions": [
        "Recognizes portfolio investment and lifecycle governance as outside the FDE bundle",
        "Routes directly to product-lifecycle",
        "Does not create an engagement charter, implementation plan, adoption scorecard, or FDE generalization record"
      ]
    },
    {
      "id": "platform-operation-negative-boundary",
      "prompt": "An internal platform team already owns a developer portal and golden-path services. It needs to design and operate the next platform capability, define its interfaces, and manage ongoing platform adoption across engineering teams. There is no external embedded engagement. What process should own it?",
      "expected_output": "The response routes direct platform design and operation to platform-engineering, without wrapping ongoing platform ownership in the FDE lifecycle.",
      "assertions": [
        "Recognizes direct internal platform design and operation as outside the FDE bundle",
        "Routes directly to platform-engineering",
        "Does not invent an FDE engagement, field-learning handoff, or separate productization ceremony"
      ]
    },
    {
      "id": "isolated-specialist-negative-boundary",
      "prompt": "A system's workflow, scope, owner, and acceptance criteria are already settled. The only remaining task is to define a retention schedule and deletion controls for personal data. No implementation or adoption continuity is requested. What process should own it?",
      "expected_output": "The response routes the bounded privacy task directly to privacy-engineering, without loading the FDE bundle or unrelated stage specialists.",
      "assertions": [
        "Recognizes that one specialist fully owns the bounded request",
        "Routes directly to privacy-engineering",
        "Does not run stakeholder discovery, the nine-stage FDE lifecycle, or load unrelated specialists"
      ]
    },
    {
      "id": "partial-and-stale-authority",
      "prompt": "A security owner documented approval for read-only log inspection. A sponsor says the CTO verbally approved exporting those logs, a database owner approved a reversible index but not the requested schema rewrite, and last quarter's budget waiver has expired. Separate what may proceed from what must stop.",
      "expected_output": "The response permits only the documented read-only inspection, refuses to launder verbal, partial, or stale authority into broader powers, and records the export, schema, and spend decisions for their authorized owners before those actions proceed.",
      "assertions": [
        "Permits the documented read-only inspection and no broader action",
        "Treats verbal assurance, partial approval, and expired approval as insufficient for the proposed export, schema rewrite, and spend",
        "Names the missing decision and authorized owner for each blocked action",
        "Does not infer one decision owner's approval applies to another authority domain"
      ]
    }
  ]
}

# Adoption and Measurement

Technical deployment is an input to adoption, not its proof. Establish a
baseline before intervention and name the intended workflow, user segment,
activation event, time-to-value, support owner, and outcome decision rule.

## Adoption diagnosis

When usage is weak, distinguish:

- **Access:** can the intended people reach and use the capability?
- **Activation:** do they complete the first meaningful workflow?
- **Workflow fit:** does it remove work or add friction compared with the current path?
- **Trust and education:** do users understand and trust the result?
- **Support and ownership:** is there help, maintenance, and a named owner?
- **Incentives and authority:** do policy, incentives, or manager expectations conflict?

Do not prescribe more training or more features until the evidence distinguishes
these causes. A technical success with poor adoption is an unresolved outcome,
not a completed engagement.

## Measurement record

For each metric record definition, baseline, target or decision rule, segment,
source, collection period, caveats, observed value, and interpretation. Separate
observed values from inferred causes. If the metric moved, test whether the
intended workflow changed and whether the change is attributable enough for the
decision being made.

For AI capabilities, pair workflow measures with evaluation evidence: quality,
failure and adversarial cases, safety or privacy constraints, latency/cost
guardrails where relevant, human override or escalation, and production feedback
that can update the evaluation set. Route statistical or instrumentation method
to the named catalog specialists.

# Authority and Escalation

## Before constrained action

Record the access route, identity and privilege needed, approved egress,
systems and data in scope, change window, reviewer, rollback or recovery path,
external-boundary verification, and evidence that the action succeeded. Load
[remote-systems-administration](../../remote-systems-administration/SKILL.md)
for its operational method rather than inventing one here.

## Authority table

| Decision | Proceed only when | Escalate to |
|---|---|---|
| Scope, sequence, and thin slice | Charter names accountable lead and sponsor | Engagement sponsor |
| Access and privilege | Authorized identity, least privilege, and route are recorded | System owner or security owner |
| Security boundary | Trust boundary, threat assumptions, and controls are reviewed | Security owner |
| Privacy and data use | Purpose, classification, access, retention, and deletion are explicit | Privacy/data owner |
| Irreversible change | Recovery is tested or an authorized exception is recorded | Service or change owner |
| Material cost or quota | Budget owner accepts estimate and guardrail | Budget owner |
| External commitment | Contract, customer, or public promise is authorized | Business owner |
| Business priority or portfolio choice | Product or executive authority decides | Product/business owner |

When authority or evidence is missing, stop the action, record the blocker,
preserve safe read-only discovery, and escalate with the smallest decision
needed. Do not use urgency, stakeholder enthusiasm, or a working demo as an
authority substitute.

## Applied AI release boundary

An applied-AI demo is not production-ready without a representative baseline,
adversarial or failure cases, risk constraints, evaluation results, an owner for
residual risk, rollout and rollback evidence, and an explicit release decision.
Route evaluation details to [agent-evals-and-observability](../../agent-evals-and-observability/SKILL.md)
and readiness details to [production-readiness](../../production-readiness/SKILL.md).

# Communication

Communication keeps an embedded engagement moving without hiding uncertainty.
Use short records with explicit labels rather than a narrative that blends fact
and promise.

## Status update

1. **Outcome:** what changed in the target workflow or decision.
2. **Evidence:** source fact or engagement observation, with artifact and date.
3. **Inference:** what the evidence may mean, including confidence and unknowns.
4. **Decision needed:** the smallest authorized choice, by whom, and by when.
5. **Commitment:** owner, deliverable, due date, and dependency.
6. **Stop/escalation:** what is blocked and what safe work can continue.

## Handoff

State the receiving owner, purpose, current stage, entry evidence, artifacts,
known limitations, unresolved risks, authority boundary, acceptance condition,
and requested response. A handoff is not complete when a link is sent; the
receiver must accept ownership or explicitly reject the boundary.

## Field learning

Report what was observed, what was tried, what changed, what failed, what may
generalize, and what should not be generalized. Label recommendations as
recommendations until the receiving authority records a decision. Avoid naming
private customers, hosts, paths, or deployment details in reusable public
artifacts.

## External-sharing gate

Treat every engagement artifact as private by default. Before any artifact
leaves the authorized engagement context, name the receiving audience and have
an accountable reviewer remove or generalize customer and stakeholder names,
people, hosts, paths, credentials, identifiers, sensitive workflow details,
security posture, commercial terms, and other context-specific information.
Record the artifact's sharing classification, reviewer, and review date. A
reusable lesson may be shared only after this gate; compliance or stakeholder
urgency does not waive it.

# Discovery Brief — Forward-Deployed Engineering

## Scope and design decision

The requested capability is designed as a public, business-agnostic continuity
bundle for embedded technical engagements. Portability is a normative design
objective, not a conclusion established by the employer-authored sources. Its
normative synthesis is the lifecycle
`Discover → Frame → Hypothesize → Build → Evaluate → Deploy → Adopt → Measure →
Generalize`, plus shared artifacts, authority gates, evidence labels, and a
generalization decision. This sequence is bundle design, not an externally
standardized methodology.

## Overlap audit

| Existing owner | Already owns | FDE bundle boundary |
|---|---|---|
| [product-discovery](../../product-discovery/SKILL.md) | Stakeholder mapping, workflow walkthroughs, hidden assumptions, validation, and interpretation handoff | Routes discovery and carries its evidence forward; does not duplicate discovery method |
| [agent-evals-and-observability](../../agent-evals-and-observability/SKILL.md) | Decision/risk contracts, datasets, baselines, graders, trajectory review, release gates, telemetry, and incident learning | Routes evaluation evidence and applies it to engagement continuity; does not restate eval method |
| [production-readiness](../../production-readiness/SKILL.md) | Risk-scaled evidence, ownership, SLOs, observability, support, security, data, rollback, capacity, cost, and verdicts | Routes readiness at the deployment boundary; does not invent a customer-site readiness method |
| [remote-systems-administration](../../remote-systems-administration/SKILL.md) | Access routes, privilege, bastions, sessions, recovery, rollback, canaries, bounded rollout, and external verification | Routes constrained-environment discovery before action; does not create a second remote-operations runbook |
| [product-lifecycle](../../product-lifecycle/SKILL.md) | Product investment and lifecycle governance | FDE owns embedded delivery continuity, not portfolio choice or product lifecycle governance |
| [production-excellence](../../production-excellence/SKILL.md) | Cross-domain production gate and handoff | FDE prepares engagement continuity and routes evidence; production-excellence owns its launch gate |
| [neckbeard](../../neckbeard/SKILL.md) | Bounded software change journey | FDE stops routing and sends a well-specified repository change directly to neckbeard |

The four audited class-level skills are not modified by this bundle. The
manifest routes to them where their existing methods are needed.

## Themes across the source set

The three sources do not establish one common role contract. Palantir supports
embedded implementation, engineering review and operation, and return of field
configurations and expertise. OpenAI supports discovery through rollout,
adoption and workflow-impact measurement, eval-driven feedback, and pattern
codification. The limited Databricks extract supports customer-facing
productionization and cross-functional work. Together they orient the bundle,
but no source proves the full nine-stage lifecycle or every artifact. They also
do not establish a universal title, staffing model, technology stack, travel
pattern, or lifecycle sequence. See [source-index.md](source-index.md).

## Design risks and mitigations

The following are risks this normative design is intended to guard against;
the source set does not establish their frequency or prevalence.

| Design risk | Continuity mitigation |
|---|---|
| Bespoke-service sprawl | Record reuse boundary and generalization decision for every local solution |
| Hero culture | Name authority, review, support, and receiving owners; make escalation normal |
| Prototype-to-production collapse | Require baseline, representative/adversarial evaluation, readiness evidence, rollback, and a release decision |
| Product bypass | Preserve field-learning and productization records; route patterns to an accountable receiving owner |
| Weak decision authority | Charter decision rights and stop conditions before action; escalate out-of-charter decisions |
| Customer capture | Define exit, transfer, adoption owner, support path, and measurable completion conditions |
| Technical success with adoption failure | Diagnose workflow, trust, education, activation, support, and ownership before more build work |

# Generalization and Productization

Local work earns a broader life through evidence, not novelty. At closeout,
classify the result and name an owner, reuse boundary, evidence, next action,
and review date.

| Classification | Use when | Required next action |
|---|---|---|
| Configuration | Existing capability and workflow are sufficient for one context | Document configuration, limits, and transfer notes |
| Reusable pattern | The workflow or implementation repeats with bounded adaptation | Package a playbook, template, or building block and test it elsewhere |
| Product capability | Multiple contexts share a stable need and supported contract | Product owner accepts scope, maintenance, support, and roadmap decision |
| Transfer/replacement | Another team or existing capability should own the outcome | Handoff owner, acceptance evidence, support boundary, and decommission plan |
| Retirement | Value, safety, feasibility, or ownership no longer justifies continuation | Communicate impact, preserve learning, and close or decommission safely |

Do not promote a local configuration to a product capability because it worked
once. Look for repeated need, transferable constraints, support economics,
security/privacy fit, measurable benefit, and a willing receiving owner. If those
are absent, keep the work local or classify it for transfer or retirement.

The productization record must distinguish engagement observations from the
inference that a pattern generalizes, the recommendation, the authorized
decision, and the commitment to implement or transfer it. Return reusable
patterns and negative learning to the appropriate product, platform, research,
or deployment owner without bypassing their authority. A classification is not
an implementation approval: route to
[implementation-planning](../../implementation-planning/SKILL.md) only after
the receiving owner approves a requirement or specification.

# Lifecycle and Artifacts

The lifecycle is a continuity contract, not a claim about industry standard
practice. The nine-stage contract — required question, minimum output, and
stop condition per stage — lives in [SKILL.md](../SKILL.md#lifecycle) and is
the single source of truth for stage expectations.

Every stage records entry evidence, the artifact produced, the accountable
decision maker, unresolved unknowns, and the next handoff in the shared
records below.

## Shared record fields

For every stage record: date, stage, accountable lead, decision authority,
entry evidence, work performed, source/evidence label, observed result,
unknowns, risks, decision rule, decision, commitment, owner, due date, and next
handoff. A stopped engagement remains a valid output if the stop reason and
learning are preserved.

Use the canonical [stage-handoff record](../templates/stage-handoff-record.md)
for those fields. Maintain [engagement status](../templates/engagement-status.md)
as the concise current-state view; it supplements rather than replaces the
stage evidence and handoff record.

# Specialist Route Selection

The stage lists in `manifest.yaml` are candidate routes, not an instruction to
load every listed skill. Load one primary specialist when its entry condition is
true. Add a secondary specialist only for a named blocker, risk, or handoff. If
one specialist fully owns the request, leave the FDE lifecycle and route the
bounded task directly.

| Stage | Candidate | Load only when | Do not load when |
|---|---|---|---|
| Discover | [product-discovery](../../product-discovery/SKILL.md) | The user, workflow, problem, outcome, or stakeholder interpretation is unvalidated | The problem and acceptance boundary are already explicit |
| Discover | [data-engineering](../../data-engineering/SKILL.md) | Discovery depends on data sources, contracts, quality, lineage, or pipeline feasibility | Data is incidental to the workflow question |
| Discover | [remote-systems-administration](../../remote-systems-administration/SKILL.md) | Relevant evidence or action sits behind remote access, privilege, egress, bastion, or recovery constraints | No remote or constrained system is involved |
| Frame | [product-design-and-ux](../../product-design-and-ux/SKILL.md) | The frame depends on user journeys, interaction behavior, service experience, or usability constraints | The work has no user-facing or workflow-experience question |
| Frame | [privacy-engineering](../../privacy-engineering/SKILL.md) | The frame includes personal data, consent, retention, disclosure, or privacy rights | No privacy-relevant data or processing is in scope |
| Frame | [secure-software-engineering](../../secure-software-engineering/SKILL.md) | The frame requires threat, trust-boundary, authentication, authorization, or secure-design decisions | Security is not a material part of the proposed intervention |
| Hypothesize | [product-experimentation](../../product-experimentation/SKILL.md) | The intervention needs a causal or comparative product/workflow experiment | The hypothesis is verified through engineering acceptance rather than an experiment |
| Hypothesize | [agent-evals-and-observability](../../agent-evals-and-observability/SKILL.md) | An agent, LLM, model, or nondeterministic workflow needs a decision/risk contract and evaluation plan | The capability is deterministic and ordinary test methods are sufficient |
| Build | [implementation-planning](../../implementation-planning/SKILL.md) | An authorized decision-maker has approved the requirement or specification and a dependency-aware delivery plan is needed | The requirement is not approved; stop and return upstream |
| Build | [backend-engineering](../../backend-engineering/SKILL.md) | The approved slice requires backend service or API implementation | No backend component is in scope |
| Build | [frontend-engineering](../../frontend-engineering/SKILL.md) | The approved slice requires a web frontend or client implementation | No frontend component is in scope |
| Build | [data-engineering](../../data-engineering/SKILL.md) | The approved slice requires data pipelines, contracts, storage, or transformation | Data work is not part of the implementation |
| Evaluate | [agent-evals-and-observability](../../agent-evals-and-observability/SKILL.md) | Agent, LLM, model, or nondeterministic behavior needs representative, adversarial, trajectory, or production-feedback evaluation | Ordinary deterministic verification is sufficient |
| Evaluate | [qa-methodology](../../qa-methodology/SKILL.md) | A risk-scaled test strategy or coverage model is needed | Acceptance criteria can be verified directly without a broader QA design |
| Evaluate | [verification-methodology](../../verification-methodology/SKILL.md) | Explicit acceptance criteria need direct pass/fail evidence | Criteria are not yet defined; return to framing or hypothesis work |
| Deploy | [production-readiness](../../production-readiness/SKILL.md) | A production or high-impact release needs a risk-scaled readiness verdict | The change is not crossing a production-like boundary |
| Deploy | [release-engineering](../../release-engineering/SKILL.md) | Release mechanics, versioning, promotion, rollback, or delivery automation are needed | No release artifact or promotion path exists |
| Deploy | [platform-engineering](../../platform-engineering/SKILL.md) | Deployment is blocked on an internal platform capability or platform-owned interface | The engagement itself is ongoing platform ownership; route directly instead |
| Deploy | [remote-systems-administration](../../remote-systems-administration/SKILL.md) | Deployment occurs through a constrained remote access or recovery path | The environment is local and unconstrained |
| Adopt | [product-adoption](../../product-adoption/SKILL.md) | Activation, onboarding, feature discovery, behavior change, or sustained use is below the decision rule | Intended workflow adoption is already evidenced |
| Adopt | [product-design-and-ux](../../product-design-and-ux/SKILL.md) | Adoption evidence points to usability or workflow-experience friction | The barrier is access, support, incentive, or ownership rather than UX |
| Measure | [product-analytics-and-measurement](../../product-analytics-and-measurement/SKILL.md) | Outcome metrics, instrumentation, events, funnels, cohorts, or governance are needed | Existing measurement evidence already answers the decision rule |
| Measure | [agent-evals-and-observability](../../agent-evals-and-observability/SKILL.md) | Model or agent quality needs production feedback and evaluation drift evidence | No agentic or nondeterministic component exists |
| Measure | [site-reliability-engineering](../../site-reliability-engineering/SKILL.md) | Reliability is an agreed outcome or a blocker to workflow impact | The request is ongoing SRE ownership; route directly instead |
| Generalize | [product-lifecycle-learning](../../product-lifecycle-learning/SKILL.md) | Expected and observed outcomes must be compared to choose continue, improve, pivot, pause, or retire | There is no post-launch evidence to compare |
| Generalize | [product-methodology](../../product-methodology/SKILL.md) | A bounded classification, prioritization, or decision log is needed for the local pattern | The question is portfolio investment or full product lifecycle governance |

## Approval boundaries

- `implementation-planning` is never a pre-approval route. A hypothesis,
  prototype, or promising field pattern is not an approved requirement.
- `product-operations-and-governance` is not a Frame-stage route for a single
  engagement decision. Load it only outside this bundle when the request is to
  design a recurring governance system.
- A Generalize-stage classification may hand an approved requirement to
  `implementation-planning` as the next owner's work. The planning skill is not
  part of the Generalize decision itself.

# Source Index

Checked 2026-08-05. These are official employer-authored role descriptions,
used only for role observations. The lifecycle, artifacts, authority protocol,
failure-mode mitigations, and generalization model are normative bundle design.
The sources come from large software and AI vendors; they do not establish that
the bundle applies universally across business, public-sector, nonprofit,
internal-service, or non-product settings. Portability is a design objective
that must be tested in the engagement context.

| Source | Authority | Supported claims | Limitations and refresh rule |
|---|---|---|---|
| [Palantir: A Day in the Life of a Palantir Forward Deployed Software Engineer](https://blog.palantir.com/a-day-in-the-life-of-a-palantir-forward-deployed-software-engineer-45ef2de257b1) | Official employer-authored role account | FDSEs embed with customers; configure existing platforms; combine software development, data engineering, customer engagement, and creative problem solving; implement collaboratively; use engineering review, deployment, maintenance, and monitoring; return configurations, workflows, and field expertise to product and deployment teams | One employee account with employer-specific products, titles, and examples. Do not universalize those details. Recheck the URL and role-account scope before materially revising source claims. |
| [OpenAI: Forward Deployed Engineer](https://openai.com/careers/forward-deployed-engineer-(fde)-sf-san-francisco/) | Current official employer role description | FDEs turn research into production systems with customers; own discovery, scoping, design, build, rollout; measure adoption and workflow impact; use eval-driven feedback; guide adoption; codify patterns and return field feedback | Employer-specific AI role description. Excludes universal employment qualifications, location, travel, mission, and stack. Recheck current role page before citing current responsibilities. |
| [Databricks: AI Engineer — FDE](https://www.databricks.com/company/careers/professional-services-operations/ai-engineer---fde-forward-deployed-engineer-8099751002) | Current official employer role description | A specialized customer-facing AI team builds and productionizes first-of-kind applications and works cross-functionally with engineering, product, developer relations, and internal SMEs | Retrieved overview exposes only these responsibilities. Do not infer missing qualifications or duties. Recheck the role page before adding claims. |

## Claim discipline

Source facts must cite one of these entries. Engagement evidence must cite the
charter, ledger, evaluation, deployment, adoption, or measurement artifact that
observed it. Inferences and recommendations must be labeled as such. A source
does not prove that a local engagement succeeded, that a pattern generalizes, or
that an authority exists.

# Worked Example — Claims-Processing Cycle-Time Reduction

A synthetic engagement that calibrates the expected depth and evidence
labeling of the continuity artifacts. All people, numbers, and workflows are
illustrative; none reference a real customer, system, or deployment. Use this
to calibrate depth, not as a template substitute.

## Engagement charter (excerpt)

- **Engagement:** Claims-processing cycle-time reduction
- **Accountable technical lead:** Assigned engagement lead
- **Sponsor and decision authority:** Operations sponsor; privacy and security
  owners gate data access; service owner approves production change
- **Stakeholders and intended users:** Claims processors, workflow
  supervisors, downstream payment roles
- **Workflow and problem statement:** Elapsed time from claim submission to
  decision is the target workflow. The bottleneck is unvalidated; no
  particular stage is assumed to be the cause.
- **Desired outcome and baseline:** Reduce median cycle time by at least 10%
  against a recorded 30-day baseline, without breaching agreed quality,
  privacy, or compliance guardrails.
- **In scope:** Read-only workflow observation; baseline measurement; one
  bounded intervention with a tested hypothesis.
- **Out of scope:** Claims policy changes; unapproved production changes;
  external commitments.
- **Constraints:** Least-privilege access; approved change windows; retention
  and deletion rules for claims data.
- **Success measure and decision rule:** Proceed to the next stage only when
  the sponsor approves the metric definition, baseline, target, and guardrails
  with named evidence.
- **Stop conditions:** No recognizable problem; no workflow access; authority
  or constraints cannot be named; evidence fails; next action exceeds charter.
- **Sharing classification:** Private by default; reviewer and review date
  recorded before any external sharing.

## Ledger entries (excerpt)

| ID | Type | Statement | Evidence / source | Confidence | Owner | Due / review | Status |
|---|---|---|---|---|---|---|---|
| A-001 | Assumption | Median cycle time is a material outcome for the engagement. | Source fact: engagement request names cycle-time reduction as the objective | High | Sponsor | Before solution design | Open |
| D-001 | Decision | No solution design until the charter establishes problem, users, workflow, outcome, scope, authority, constraints, success measure, and stop conditions. | Decision: engagement design gate | High | Sponsor and lead | Ratified | Active |
| R-001 | Risk | Optimizing cycle time could degrade claim quality if guardrails are not explicit. | Inference: guardrails not yet defined | Medium | Operational risk owner | Before hypothesis approval | Open |

## Stage handoff — Build to Evaluate (excerpt)

- **Entry evidence:** Approved requirement; thin-slice implementation plan with
  owner; charter and ledger current.
- **Work performed:** Thin slice built and tested against acceptance criteria.
- **Source / evidence labels:** Each test result labeled engagement observation;
  design choices labeled decisions.
- **Observed result:** Slice passes technical acceptance; no production claim.
- **Unknowns:** Production data behavior; operator workflow interaction.
- **Decision rule:** Advance to Evaluate when representative evidence exists.
- **Decision:** Advance to Evaluate.
- **Receiving owner / acceptance condition:** Evaluation owner accepts the
  slice and baseline evidence.

## Evaluation and release decision (excerpt)

- **Baseline and decision thresholds:** Median 30-day cycle time; 10%
  reduction rule; quality guardrails.
- **Representative evidence:** Workflow sample spanning claim types, channels,
  and processor experience levels.
- **Adversarial or misuse evidence:** Boundary inputs, partial data, and
  worst-case queue conditions.
- **Known constraints and residual risks:** One segment shows 8% adoption;
  support owner not yet named.
- **Rollout / rollback prerequisites:** Authorized change window; recovery
  path tested; verification method named.
- **Release decision:** Conditional — approve with the adoption plan and
  support owner recorded as conditions.

## Adoption scorecard (excerpt)

- **Target workflow and users:** Claims processors in the two busiest teams.
- **Activation event:** First claim completed with the new path.
- **Adoption metric and decision rule:** 60% of eligible processors active
  within 30 days.
- **Outcome metric and decision rule:** Median cycle-time reduction >= 10%
  with quality guardrails intact.
- **Observed:** Team A 64% active; Team B 8% active.
- **Blockers recorded:** Team B workflow-fit and support evidence missing;
  incentive alignment unexamined.
- **Interpretation:** Adoption gap is unexplained; more training or features
  are not prescribed until access, fit, trust, support, and incentives are
  distinguished.

## Outcome measurement record (excerpt)

- **Observed result:** 12% median reduction against the 10% rule.
- **Uncertainty and confounders:** Two-week window; concurrent process
  changes; segment imbalance.
- **Decision:** Continue with the adoption intervention; re-measure at 60
  days.

## Productization record (excerpt)

- **Observed local result:** 12% reduction; adoption strong in one segment,
  weak in another.
- **Reuse hypothesis:** The intervention may transfer to similar
  intake-to-decision workflows.
- **Classification:** Configuration — provisional, local-only. A single
  positive outcome, weak adoption in one segment, and no willing receiving
  owner are insufficient evidence for a reusable-pattern or product-capability
  classification.
- **Reuse boundary:** Restricted to the current authorized context until
  repeated need, transferable constraints, support economics, and a receiving
  owner are evidenced.
- **Recommendation:** Candidate pattern for a pilot transfer; the receiving
  product owner must approve a requirement before implementation-planning is
  routed.
- **Decision authority and decision:** Pending; recommendation is not a
  decision.
- **Field learning returned to:** Internal platform and product owners, with
  the external-sharing gate applied.

## What this example is for

Calibrate the depth and evidence discipline expected of each artifact:
separate observations from inferences, apply the declared decision rule,
record missing evidence as bounded uncertainty, label every material entry,
and keep the classification and recommendation separate from any authorized
decision. Do not copy the illustrative numbers or the synthetic workflow into
a real engagement.

# Adoption Scorecard

- **Capability and target workflow:**
- **Intended users / segment:**
- **Workflow owner and support owner:**
- **Baseline period and source:**
- **Activation event:**
- **Time-to-value baseline / target:**
- **Adoption metric and decision rule:**
- **Outcome metric and decision rule:**
- **Access or privilege blockers:**
- **Workflow-fit evidence:**
- **Trust / education evidence:**
- **Support / ownership evidence:**
- **Intervention:**
- **Observed result:**
- **Interpretation and remaining uncertainty:**
- **Decision:**
- **Sharing classification / sanitization reviewer:**

# Assumptions, Decisions, and Risks Ledger

| ID | Type | Statement | Evidence / source | Confidence | Owner | Due / review | Status |
|---|---|---|---|---|---|---|---|
| A-001 | Assumption | | | | | | Open |
| D-001 | Decision | | | | | | Open |
| R-001 | Risk | | | | | | Open |

- **Sharing classification / sanitization reviewer:**

## Evidence labels

Use exactly one primary label for each entry: source fact, engagement
observation, inference, recommendation, decision, or commitment. Link the
artifact or observation that supports it. Record disconfirmation and the next
decision rule instead of silently rewriting the entry.

# Engagement Charter

- **Engagement:**
- **Date / revision:**
- **Accountable technical lead:**
- **Sponsor and decision authority:**
- **Stakeholders and intended users:**
- **Workflow and problem statement:**
- **Desired outcome and baseline:**
- **In scope:**
- **Out of scope:**
- **Constraints:**
- **Access and privilege boundary:**
- **Success measure and decision rule:**
- **Stop conditions:**
- **Rollback / recovery boundary:**
- **Planned lifecycle stages:**
- **Open unknowns:**
- **Next decision and owner:**
- **Sharing classification / sanitization reviewer:**

Record observations, inferences, recommendations, decisions, and commitments
separately in the ledger.

# Engagement Status

- **Engagement / revision:**
- **Date:**
- **Current stage:**
- **Overall state:** Discover / Active / Blocked / Stopped / Complete
- **Outcome movement:**
- **Evidence observed:**
- **Inference / confidence:**
- **Work completed:**
- **Next decision:**
- **Decision authority and due date:**
- **Risks and unknowns:**
- **Escalation:**
- **Commitments:**
- **Next handoff:**
- **Sharing classification / sanitization reviewer:**

# Evaluation and Release Decision

- **Capability / version / environment:**
- **Evaluation owner:**
- **Decision authority:**
- **Baseline and decision thresholds:**
- **Representative evidence:**
- **Adversarial or misuse evidence:**
- **Operational and trajectory evidence:**
- **Known constraints and residual risks:**
- **Rollout / rollback prerequisites:**
- **Release decision:** Approve / Conditional / Reject
- **Conditions or stop reason:**
- **Receiving owner / acceptance condition:**
- **Sharing classification / sanitization reviewer:**

# Field Learning Record

- **Engagement boundary:**
- **Observed workflow outcome:**
- **Evidence and source labels:**
- **What was local or environment-specific:**
- **What may transfer, and within what boundary:**
- **Unresolved uncertainty / risks:**
- **Generalization classification:**
- **Decision authority and decision:**
- **Receiving owner / acceptance condition:**
- **Committed next action / due date:**
- **Public-safe summary after sanitization:**
- **Sharing classification / sanitization reviewer:**

# Outcome Measurement Record

- **Capability / target workflow:**
- **Accountable owner:**
- **Agreed outcome and decision rule:**
- **Baseline / comparison:**
- **Instrumentation and evidence source:**
- **Observation window / population:**
- **Expected result:**
- **Observed result:**
- **Uncertainty and confounders:**
- **Decision:** Continue / Improve / Pivot / Pause / Retire
- **Committed next action / due date:**
- **Receiving owner / acceptance condition:**
- **Sharing classification / sanitization reviewer:**

# Productization Record

- **Engagement / capability:**
- **Observed local result:**
- **Evidence artifacts:**
- **Reuse hypothesis:**
- **Classification:** Configuration / Reusable pattern / Product capability / Transfer-replacement / Retirement
- **Reuse boundary and known non-generalizable conditions:**
- **Security, privacy, support, and cost implications:**
- **Receiving owner:**
- **Recommendation:**
- **Decision authority and decision:**
- **Committed next action / due date:**
- **Field learning returned to:**
- **Sharing classification / sanitization reviewer:**
- **Retained uncertainty:**

# Stage Handoff Record

- **Date / stage:**
- **Accountable lead:**
- **Decision authority:**
- **Entry evidence:**
- **Work performed:**
- **Source / evidence labels:**
- **Observed result:**
- **Unknowns:**
- **Risks:**
- **Decision rule:**
- **Decision:**
- **Commitment:**
- **Receiving owner / due date:**
- **Acceptance condition:**
- **Next stage or stop reason:**
- **Sharing classification / sanitization reviewer:**

# Stakeholder and Workflow Map

| Stakeholder / role | Need or job | Current workflow | Friction / risk | Evidence source | Decision or influence | Follow-up owner |
|---|---|---|---|---|---|---|
| | | | | | | |

- **Sharing classification / sanitization reviewer:**

## Workflow slice

- **Trigger:**
- **Inputs and data:**
- **Steps:**
- **Tools and handoffs:**
- **Decision points:**
- **Failure and recovery path:**
- **Current baseline:**
- **Desired change:**
- **Unknowns requiring observation:**