LockedIn FDE Benchmark v0.1 Specification

Status: Public Draft
Release line: 0.1.x
Official numeric scoring: Disabled
Steward: LockedIn Labs
Last substantive update: August 31, 2026

This document defines the public benchmark construct and the minimum requirements for implementations that claim alignment with the LockedIn FDE Benchmark v0.1 Public Draft.

1. Document authority

Sections 2 through 16 are normative unless explicitly labeled informative. Section 17 is informative.

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL express requirement strength in the conventional standards sense.

Released machine schemas are normative for interchange where this specification or a release manifest names them. The benchmark card constrains intended use. The charter and governance policy govern changes to this specification.

2. Release posture

Version 0.1 is a proposed, field-evidence-oriented benchmark framework. It has not established predictive validity, general population norms, calibrated score bands, independent certification, or fitness for automated employment decisions.

Conforming v0.1 implementations:

• MUST identify the release as a public draft;
• MUST keep official numeric scoring disabled;
• MUST label every included person, artifact, deployment, observation, and result example as synthetic;
• MUST NOT issue a verified credential or imply certification under this release;
• MUST distinguish implemented, experimental, controlled, and planned capabilities;
• MUST NOT claim that the benchmark is unbiased, independently validated, predictive, immutable, an industry standard, or endorsed by an outside organization without separately documented evidence and authorization.

3. Construct and unit of measurement

The benchmark construct is demonstrated Forward Deployed Engineering capability. Forward Deployed Engineering is treated as an operating model: hands-on engineering performed in or alongside a customer environment, with responsibility spanning discovery, implementation, production adoption, and a field-to-product learning loop. It is not defined as an AI-exclusive job title.

The declared role context for v0.1 is AI-native Forward Deployed Engineering: applying that operating model to AI-enabled systems and workflows. The release combines portable FDE capabilities with explicit AI-system evaluation, data, model behavior, agentic workflow, safety, governance, and production-operation requirements. It MUST NOT be represented as validated for every FDE role or for non-AI deployment contexts.

Security, financial infrastructure, telecommunications, defense, industrial, and other forward-deployed contexts MAY be considered in later releases. Each context requires a separately versioned domain pack, job or practice analysis, content blueprint, administration conditions, validation plan, and governed release decision. Core capabilities MAY be reused as hypotheses; validity MUST NOT be assumed to transfer from the AI-native context.

For this specification, the LockedIn FDE Benchmark is a versioned, purpose-bound assessment system for collecting, reviewing, and interpreting evidence of that construct in a defined role context. A complete benchmark release binds: (1) a target population and context; (2) intended interpretations, uses, and prohibited uses; (3) a construct model; (4) a content blueprint connecting job activities, observable behavior, tasks, artifacts, and rubric criteria; (5) standardized administration and evidence conditions; (6) measurement and decision rules; (7) validity, reliability, fairness, uncertainty, and consequence evidence for the stated use; and (8) a governed, reproducible release record.

Version 0.1 defines parts of that system as a public draft. It MUST NOT be described as a validated assessment, official qualification, certification scheme, or authorized hiring instrument. The benchmark formation protocol is informative and records the evidence required to advance those states.

For this AI-native release context, a Forward Deployed Engineer is a practitioner who can work in or alongside an enterprise environment to:

1. discover and frame a consequential problem;
2. translate operational needs into a technical plan;
3. design an appropriate system and control boundary;
4. build or direct hands-on implementation;
5. evaluate AI and software behavior;
6. integrate data, infrastructure, identity, and workflows;
7. navigate security, governance, and production gates;
8. operate, remediate, and improve the system;
9. substantiate technical and business outcomes; and
10. transfer reusable capability to customer and product organizations.

The primary unit of measurement is an individual practitioner. Team, organization, specialization, and role-readiness views MAY be derived later, but MUST remain distinguishable from an individual capability result.

The benchmark measures evidence about work. It does not measure human worth, general intelligence, likability, fame, employer prestige, school prestige, or social reach.

4. Intended and prohibited uses

The v0.1 public draft is intended for:

• public review of the proposed construct and evidence model;
• ontology, rubric, integrity, accessibility, and governance research;
• synthetic demonstrations of evidence lineage and deterministic calculation;
• practitioner self-reflection that is clearly labeled self-evaluated;
• planning a controlled calibration study.

It MUST NOT be used to:

• automatically reject, hire, terminate, promote, compensate, discipline, rank, or staff a person;
• represent a person as certified, verified, or field validated by the v0.1 system;
• publish an official numeric score or percentile;
• collapse a public human capability profile into one global number;
• rank named people on a public leaderboard;
• publish or infer a cost-per-person, compensation-efficiency, or “value for money” axis;
• infer low capability solely from missing or private evidence;
• require a public source-control profile;
• expose customer-confidential or candidate-private information;
• imply that training, employment, payment, sponsorship, or use of a particular platform earns credit.

See BENCHMARK_CARD.md for further use limitations.

5. Capability ontology

The normative hierarchy is:

Domain
  → Capability Family
    → Competency
      → Atomic Signal
        → Rubric Criterion

Each released object MUST have a stable identifier, name, definition, version provenance, lifecycle status, and parent reference. Revisions that alter meaning MUST create a new version or identifier under the release policy.

The ten top-level domains are:

1. Forward-Deployed Discovery and Problem Framing — discovery, ambiguity reduction, outcome definition, prioritization, and customer trust.
2. Software and Systems Engineering — implementation, interfaces, data, delivery, testing, reliability, performance, and maintainability.
3. AI-Native and Agentic Engineering — models, grounding, agents, tools, evaluation, guardrails, failure handling, observability, cost, and red teaming.
4. Architecture and Technical Judgment — current-state analysis, tradeoffs, boundaries, integration, resilience, migration, and reuse.
5. Enterprise Readiness, Security, and Governance — privacy, identity, threat modeling, auditability, compliance translation, accessibility, and continuity.
6. Production Deployment and Operations — rollout, rollback, acceptance, service objectives, incident response, drift, ownership, and handoff.
7. Business Outcomes and Value Realization — baselines, metrics, attribution, adoption, persistence, and stop/iterate/scale judgment.
8. Forward-Deployed Communication and Leadership — workshops, decision clarity, negotiation, pressure, mentoring, cross-functional leadership, and capability transfer.
9. Modernization and Transformation — legacy discovery, decomposition, migration, platform modernization, sequencing, adoption, and transformation governance.
10. Domain Specialization — separately versioned domain or technology contexts that MUST NOT distort the vendor-neutral core.

The ontology release, rather than this summary, defines the released family inventory. Candidates MUST NOT be presented with the ontology as a single exhaustive questionnaire; evaluation SHOULD target meaningful uncertainty.

6. Evidence model

An implementation MUST separate:

• EvidenceItem — metadata for a submitted source or artifact;
• EvidenceClaim — an assertion supported or contradicted by evidence;
• EvidenceCapabilityLink — the assessed relationship between a claim and capability;
• EvidenceVerificationEvent — an append-only verification action or outcome;
• EvidenceLineageGroup — correlated or derivative evidence that must not be counted as independent support;
• ArtifactObject — private raw content, which is outside the public repository and audit-event payload.

Evidence maturity is ordinal and MUST be assigned to a specific claim-to-capability link:

Maturity does not by itself determine proficiency. A mature artifact can demonstrate a poor decision, limited ownership, or contradictory evidence. E1 credit from a credential MUST depend on documented relevance and quality; course completion alone MUST NOT add credit.

7. Independent status axes

Implementations MUST NOT collapse these axes into one status field:

An E5 evidence link does not automatically create a field-validated public result. Public result rules may require coverage, independent review, identity checks, integrity clearance, and evidence from more than one capability.

8. Evidence requirements

Every evidence item or capability link, as applicable, MUST retain:

• source and provenance;
• subject and ownership scope;
• collection method and time;
• applicable benchmark and schema versions;
• related claims and capability identifiers;
• maturity and verification information;
• attribution confidence and unresolved ambiguity;
• recency, complexity, responsibility, and limitations;
• lineage and independence relationships;
• integrity state;
• confidentiality classification;
• consent grant and permitted uses;
• reviewer or evaluator version;
• a digest or signed attestation where appropriate;
• retention, review, withdrawal, and deletion policy references.

Repository, commit, follower, credential, or line-of-code counts MUST NOT be direct capability measures. Public and private evidence pathways MUST be treated as equivalent when they demonstrate the same construct under equivalent verification rules.

Raw personal, customer, or artifact content MUST NOT enter an append-only event log. See DATA_GOVERNANCE.md.

9. Evaluation and result classes

The proposed result classes are:

• Self-Evaluated — produced by a person using public material; not independently verified.
• Provisional — evaluated evidence exists, but one or more required verification or review steps remain incomplete.
• Verified — the release’s identity, evidence, review, and integrity protocol has been met.
• Field Validated — verified status plus qualifying production evidence and contribution corroboration under the release protocol.

These classes are design targets in v0.1. This release MUST NOT issue official Verified or Field Validated results.

9.1 Outcome authority layers

Result class is not the same thing as a factual record, a capability interpretation, or a credential decision. Future releases MUST keep three output authorities separate:

1. Verified Production Record — bounded, contestable facts corroborated under a named protocol, such as deployment existence, contribution scope, artifact existence, or an observed outcome measure. It MUST NOT assert capability, readiness, causality, a score, or a tier merely because a fact was verified.
2. Capability Profile — a versioned, multidimensional interpretation of eligible evidence for a declared construct, role, population, administration condition, and intended use. It MUST preserve coverage, support confidence, uncertainty, evidence maturity, contradictions, critical gates, and Insufficient Evidence. It is not a validated psychometric instrument until the required validity and reliability evidence exists for the stated interpretation and use.
3. Governed Credential Tier — a later, time-bounded classification issued under a released scheme with standard setting, independent decision authority, status, expiry, correction, appeal, suspension, and revocation. A signed credential proves issuer authenticity and integrity; it does not make the underlying capability claim true.

Every downstream output MUST bind the exact upstream versions and digests without overwriting their history. No layer may silently confer another. The proposal and non-operational machine contracts are documented in the Outcome Architecture and Shared-Work Research Proposal.

Adaptive evaluation SHOULD follow:

Evidence
  → Capability hypothesis
  → Uncertainty analysis
  → Targeted challenge
  → Structured observation
  → Human review or adjudication
  → Capability-state update
  → Next challenge

Candidate-specific evidence SHOULD drive follow-up questions when available. Controlled cases MUST be separated from public practice cases.

10. AI and human authority

AI evaluators MAY normalize evidence, propose mappings, identify uncertainty, generate targeted questions, and produce structured observations.

An AI evaluator:

• MUST output against a released schema;
• MUST identify its provider, model, policy, prompt, and evaluator versions as allowed by the release manifest;
• MUST cite the evidence and rubric used;
• MUST expose confidence, contradictions, limitations, and integrity flags;
• MUST NOT write a final score, verification status, credential, or adjudication;
• MUST NOT receive authority based on provider identity or marketing claims.

Only an eligible reviewer-accepted observation with its bound human-review record may become a v0.1 scoring input. An adjudicated outcome cannot become numeric authority until a later released contract binds and verifies the complete adjudication artifact. High-consequence qualification remains human-governed. See SCORING.md.

11. Capability, confidence, coverage, and maturity

These concepts MUST remain separate:

• Capability estimate — what eligible observations support about demonstrated performance.
• Support confidence — the strength, independence, agreement, and quality of evidence supporting the estimate.
• Coverage — how much of the required benchmark scope has adequate evidence.
• Evidence maturity — the E0–E5 level of a specific evidence-capability link.
• Verification class — the completed verification protocol, not a score.

Authoritative numeric quantities MUST use integer basis points from 0 through 10,000. Display percentages or qualitative labels MUST be deterministic projections from a versioned display policy.

Insufficient evidence MUST produce Insufficient Evidence, not a zero or inferred low capability. Severe weakness in a critical domain MUST NOT be hidden by a weighted average. Integrity failures MUST be handled as eligibility or gate decisions, not as a soft multiplier.

Official numeric scoring is disabled for all v0.1 releases. Requirements for synthetic experimental calculations appear in SCORING.md.

The phrase FDE Score is reserved and MUST NOT appear as a real-person product or official result in v0.1. A future scalar is not categorically impossible, but it would create a new score interpretation and use. It requires a new release, dimensionality and aggregation evidence, calibrated uncertainty, standard setting for any classification, fairness and consequence research, independent review, and the activation gate in SCORING.md. Governance cannot make a scalar scientifically defensible merely by voting to remove the current prohibition.

11.1 Proposed research-profile dimensions

The public research posture is method-first and multidimensional. These dimensions are research candidates, not active v0.1 indices:

• Demonstrated Capability — the canonical v0.1 output is a profile across released domains and competencies, not a single global number. A later purpose-bound scalar, if ever authorized under a new release, would be a separately labeled projection and MUST NOT replace the profile, uncertainty, coverage, critical-domain floors, or Insufficient Evidence state.
• Time to Production — a candidate measure of elapsed time from a predeclared, evidence-supported start event to a governed production state. It is not typing speed, working hours, individual “velocity,” or a cost proxy.
• Evidence Strength — the corroboration, attribution, independence, maturity, and lineage quality supporting a claim. It is evidence about the estimate, not capability itself.
• Recency — when the relevant capability was demonstrated under a capability-specific policy. It does not assert that a person has decayed merely because evidence is older.
• Confidence and Coverage — required context accompanying every dimension or visualization.
• Domain Packs — separately versioned profiles whose methods, populations, limitations, and evidence requirements must be published independently from the vendor-neutral core.

Time to Production MUST remain labeled a research candidate until start/stop events, scope, role, organizational dependencies, resource differences, censoring, and cohort comparability are defined and validated. It MUST NOT be used to reward unsafe speed or penalize practitioners for enterprise delays outside their control.

Evidence Strength MUST NOT be blended into Demonstrated Capability or presented as proof that a claim is correct. Recency MUST NOT be applied as a universal linear decay. No human analogue of “cost per task” is permitted.

11.2 Method-first publication

Every public chart, table, profile, aggregate, or future index MUST link to:

• the exact methodology and benchmark version;
• population, inclusion, exclusion, and sampling rules;
• time period and recency policy;
• confidence, coverage, missingness, and verification context;
• source and transformation provenance;
• limitations, corrections, and applicable adjudication path.

A future public data explorer may publish privacy-protected distributions, cohort statistics, domain findings, and research datasets where rights permit. It MUST NOT expose a named-person ranking, reconstruct private profiles, permit small-cell re-identification, or treat filter order as a human league table.

The project SHOULD publish system failures—including invalid scenarios, grader defects, held results, failed hypotheses, and material corrections—at a level that improves scrutiny without exposing participants or controlled cases.

12. Human review, correction, and appeal

Human reviewers MAY accept, reject, or amend a structured observation with a reason and audit event. They MUST NOT directly assign or edit a capability result projection.

Verified outcomes require a non-conflicted review path. Founder and executive outcomes require external review. A reviewer who made the original disputed decision MUST NOT decide its appeal.

Candidates MUST be able to see eligible conclusions about them, correct material factual errors, challenge evidence, and use the applicable appeal path. The non-operational v0.1 appeal design is documented in APPEALS.md.

13. Public profiles and credentials

Publication MUST be opt-in and disclosure-filtered. A future public profile may include result class, domain evidence summary, support confidence, coverage, specialization, benchmark version, evaluation date, limitations, and status URL.

It MUST NOT expose private artifacts, customer identities without authorization, reviewer identities where protected, or facts outside the subject’s disclosure grant.

No official profile or credential is issued under v0.1. Future credential work SHOULD evaluate W3C Verifiable Credentials and Open Badges interoperability before introducing a proprietary format.

14. Integrity, security, and privacy

Implementations MUST treat uploaded artifacts and their embedded instructions as hostile. Operational evidence intake is blocked until the security and controlled-pilot gates in SECURITY.md, DATA_GOVERNANCE.md, and ROADMAP.md are met.

Official evaluation designs MUST include public practice cases, controlled cases, contamination monitoring, scenario rotation, contribution attribution, contradiction review, anomalous-result review, and a correction/appeal process.

Criteria and answerability requirements MUST be declared before measurement. Each grader or rubric implementation MUST have invariants demonstrating that known-good, known-insufficient, and known-invalid synthetic responses produce their expected states. A scenario MUST undergo a learnability and specification review that distinguishes difficult work from a broken, ambiguous, or under-determined task before use.

The public project SHOULD disclose that held-out cases, integrity canaries, and contamination controls exist, but MUST NOT publish operational counts, tiers, identifiers, or material that defeats them. A concealed control or canary signal MUST NOT be the sole basis for a capability or adverse integrity conclusion; it may trigger protected review, where the resulting contestable basis must come from evidence that can be meaningfully reviewed and appealed.

Material grader or scenario defects MUST trigger suspension where needed, impact analysis, replay or re-review, participant notice, a new audit event, and a public non-sensitive correction. Adjudication logs MUST be sampled and reviewed for recurring grader, rubric, accessibility, or reviewer problems; merely offering adjudication is insufficient.

Use of any particular tool, LockedIn employment, LockedIn training, payment, sponsorship, friendship, school, employer prestige, fame, and social following MUST NOT be score inputs.

15. Employment and accessibility safeguards

The v0.1 benchmark MUST NOT be used as an automated employment cutoff.

Any future high-impact employment use requires, at minimum:

• demonstrated job relevance and a defined target role;
• human review and accountable decision ownership;
• candidate notice where required;
• an accommodation and alternate-demonstration process;
• correction and appeal;
• auditability and fairness monitoring;
• applicable legal and measurement review;
• explicit prohibition on facial, emotion, or personality inference unrelated to the construct.

Before any use involving workers, candidates, or employers, qualified counsel MUST determine the applicable current requirements for each jurisdiction and use. Areas for counsel review may include the EU AI Act, NYC Local Law 144, Colorado employment-AI legislation, Illinois AI/video-interview and employment-AI law, GDPR Article 22, and other employment, discrimination, privacy, consumer, accessibility, and automated-decision rules. This list is a research prompt, not a legal conclusion that a named law applies or that these are the only relevant obligations.

Multiple demonstration modes SHOULD be designed to preserve the job-relevant construct while reducing irrelevant communication, disability, geography, or tool-access barriers.

16. Versioning, conformance, and comparability

A released benchmark version is immutable. Corrections create a new patch release; construct or scoring changes require a new compatible or breaking release according to the published release policy.

Every result artifact MUST name:

• benchmark, ontology, schema, rubric, scoring-policy, and evaluator versions as applicable;
• evaluation date;
• result class;
• confidence and coverage representation;
• evidence-set digest or reproducibility reference;
• limitations and dispute/revocation state.

Results from different benchmark versions MUST be displayed as version-separated unless a published linking or equating study authorizes comparison. A profile MUST NOT draw a continuous improvement line across unlinked versions.

An implementation may claim v0.1 schema conformance only if it passes released schema and invariant tests. It may claim v0.1 specification alignment only if it also satisfies the normative behavioral requirements in this document. Neither claim means that the implementation is validated, certified, or authorized to issue official results.

17. Informative design rationale

The benchmark combines established ideas rather than claiming each component as novel: real-work capability frameworks, performance-based technical assessment, versioned AI evaluation, public-versus-controlled cases, evidence provenance, human adjudication, portable credentials, and ongoing measurement of the measurement system itself.

The differentiated research question is:

Which observable, verified signals most reliably support successful enterprise AI deployment by a Forward Deployed Engineer?

Answering that question requires longitudinal evidence. It is not answered by the v0.1 public draft.

The research program may study a Shared Work Challenge Battery that binds human-only, model-only, and human-with-AI conditions to a common versioned scenario substrate. Shared tasks do not establish construct equivalence or score comparability; results remain condition-specific unless a later linking or measurement-invariance study, statistically robust human baseline, and independently authorized comparison interpretation support a narrower claim.

The public research program may later study adjacent AI delivery roles only after the FDE construct has met its validation and governance gates. Each additional role requires its own job analysis, construct boundaries, evidence model, domain mapping, validation plan, and release decision; FDE findings MUST NOT be assumed to transfer.

Related documents: BENCHMARK_CARD.md · SCORING.md · Outcome architecture and shared-work proposal · GOVERNANCE.md · INDEPENDENCE_FIREWALL.md · DATA_GOVERNANCE.md · LIVE_VS_PLANNED.md