LockedIn FDE Benchmark

Status: v0.1 Public Draft. This repository defines a proposed benchmark framework and synthetic reference artifacts. It does not issue official numeric scores, verified profiles, certifications, or employment recommendations.

The LockedIn FDE Benchmark is a public, field-evidence-oriented framework for describing and evaluating demonstrated Forward Deployed Engineering capability. Its v0.1 release context is AI-native Forward Deployed Engineering: the people responsible for moving AI-enabled systems from ambiguous enterprise need into governed production use and measurable operating outcomes.

Forward Deployed Engineering is the broader operating model, not an AI-exclusive job title. This public draft defines its proposed construct in an AI-native context first. Later security, financial-infrastructure, telecommunications, defense, industrial, or other context packs require their own practice analysis, blueprint, validation evidence, and governed release; v0.1 findings do not automatically transfer.

Its founding principle is:

Forward Deployed Engineering is demonstrated, not declared.

The project is founded and initially stewarded by LockedIn Labs. Its methodology is intended to be open to public review while private evidence, official cases, integrity controls, and operational verification remain controlled.

Start here

• Specification — normative construct, evidence, evaluation, and versioning requirements.
• Benchmark card — intended use, exclusions, maturity, and limitations.
• Scoring architecture — deterministic-scoring boundary and publication restrictions.
• Ontology and schemas — versioned public machine-readable foundations.
• Live versus planned — the authoritative capability-status register.
• Charter and governance — mission, authority, decisions, and independence.
• Independence and institutional firewall — external-majority governance, role/data/funding separation, reserved claims, and the required structural-entity decision; these controls are specified but not yet operational.
• Data governance, security, and appeals — trust controls and release gates.
• Research source ledger and dated market landscape — current design inputs, departures, monitoring, and strategic implications.
• Commissioned-interview intake protocol, study register, and aggregate substantiation rules — the evidence gate for any public research-size or research-backed claim.
• Research publication template and chart/data-product contract — the proposed operating format for citable releases and inspectable visual claims.
• Phase 2 research agenda — the proposed studies and activation gates for trust progression and readiness, verification, integrity controls, multidimensional measurement, and the aggregate register.
• Phase 2 trust and register proposal — isolated, nonnormative T0–T4 trust progression, separate operational readiness and result lifecycle, 12-axis composition, behavioral-integrity, appeal, refresh, and aggregate-publication contracts; none is operational, result-issuing, or score-authorizing.
• Three-layer outcome and Shared Work Challenge proposal — separates factual production records, multidimensional capability profiles, and future governed credential tiers; defines a condition-specific human/model/shared-task research design and a fail-closed authorization gate for any future scalar.
• Citation metadata and reference library — machine-readable draft citation guidance and primary research references; no DOI or formal release is claimed.
• Draft release packet — byte-manifest process and publication decision template; currently unapproved.
• Production operations — verified hosting state, commit-pinned deployment, live monitoring, rollback, and release-evidence controls for the indexable public draft.
• Roadmap and changelog — gate-based delivery and release history.

What the AI-native release is designed to assess

The construct combines a portable FDE core with explicit AI-system delivery requirements and separately versioned context packs. It spans ten domains:

1. Forward-deployed discovery and problem framing.
2. Software and systems engineering.
3. AI-native and agentic engineering.
4. Architecture and technical judgment.
5. Enterprise readiness, security, and governance.
6. Production deployment and operations.
7. Business outcomes and value realization.
8. Forward-deployed communication and leadership.
9. Modernization and transformation.
10. Domain specialization.

Evidence is considered at six maturity levels, from E0 claimed through E5 field validated. Maturity is assessed for a specific evidence-to-capability link; it is not a blanket label applied to a person or an entire repository.

The isolated Phase 2 proposal uses T0–T4 only for historical trust-progression milestones. Current readiness routes work, and result lifecycle records the state of a separately governed artifact. Neither is E0–E5, capability, a credential, disclosure permission, or an issued result.

What v0.1 is not

The public draft is not:

• an industry standard or accredited personnel certification;
• a validated predictor of hiring or job performance;
• an automated employment decision system;
• a résumé keyword score, coding quiz, or training badge;
• a public leaderboard of named people or measure of general intelligence;
• a recruiting, staffing, or commercial recommendation funnel presented as neutral benchmark authority;
• proof that any person, company, sponsor, or platform is preferred;
• an operational service for uploading private repositories or customer evidence.

All examples and fixtures in this repository are synthetic. No public GitHub profile is required by the proposed benchmark, and absence of evidence must produce an Insufficient Evidence state rather than an assumed low capability result.

Research and calibration status

The repository now contains a public method-paper interface, a controlled interview-study intake contract, and an experimental measurement/calibration foundation. These components make the proposed construct, task sequence, evidence model, research status, calculation boundary, and source record inspectable together.

LockedIn Labs has reported a previously commissioned interview target of at least 500 AI practitioners and 50 executives. The underlying participant records and study artifacts are not present in this repository, so the figures remain an unverified requestor assertion and contribute zero admissible observations. The study register defines the exact evidence required before any count or “research-backed” wording can be released.

The experimental scorer may exercise synthetic criterion, task, rater, missingness, uncertainty, and calibration interfaces. It is not a fitted production model. Real-person training and publication remain blocked until a frozen, consented, role-relevant dataset and independent validation program satisfy the declared release gates.

Repository boundary

This public repository may contain:

• the specification, benchmark card, ontology, public schemas, and change history;
• governance, contribution, security, data, conflict, appeal, and trademark policies;
• public sample cases using synthetic data;
• an experimental reference scorer and evaluator interfaces;
• a public explanatory site.

Source code for the current explanatory site is in apps/public-site. Presence in this repository does not mean that it has been deployed to a LockedIn Labs domain.

It must never contain:

• private candidate or customer evidence;
• hidden official cases or holdouts;
• private evaluator prompts, fraud heuristics, or adjudication records;
• production credentials, secrets, identity documents, or confidential code.

The future operational platform and private evaluator are separate security and repository boundaries. Use of any particular tool, training programs, employment by LockedIn, sponsorship, and payment cannot change benchmark scoring rules.

Normative and informative material

The specification identifies its normative requirements. Released schemas are normative for machine interchange within the release that names them. Explanations, examples, research notes, sample cases, and roadmap items are informative unless a normative document explicitly incorporates them.

If two documents conflict, the specification controls benchmark behavior, the charter and governance policies control project decisions, and the live-versus-planned register controls claims about current availability.

Participate

Public review is welcome through issues and RFCs once repository contribution channels are enabled. Read CONTRIBUTING.md, CODE_OF_CONDUCT.md, and CONFLICT_OF_INTEREST.md before participating.

Do not submit private code, personal data, customer information, security vulnerabilities, or purported hidden evaluation material through public channels.

Release and licensing posture

The v0.1 line remains a public-draft and calibration line. It cannot become an official-scoring release through a configuration change. Official scoring requires a later benchmark version and the gates in SCORING.md, BENCHMARK_CARD.md, and ROADMAP.md.

Reference software, machine schemas, synthetic fixtures, scripts, and the public site source are licensed under the Apache License 2.0 (LICENSE). Specification, policy, ontology, and research content is licensed under CC BY 4.0 (LICENSE-CONTENT.md); attribution terms are in NOTICE. Neither grant covers names, logos, or release marks, and neither authorizes describing a copy, fork, evaluation, or credential as official. Trademark permission is separate; see TRADEMARK_POLICY.md.

Stewardship

LockedIn Labs is the founding steward. That role does not permit direct score assignment, preferential treatment, or sponsor influence. Current governance status and any seated bodies must be disclosed in LIVE_VS_PLANNED.md.