GATE 01FLOOR · 3/4
Requirements traceability
Every material requirement, exclusion, assumption, and acceptance decision is versioned and traceable to implementation and evidence.
- Requirement ledger
- Acceptance matrix
- Decision log
[ FDE PRODUCTION PROJECT REVIEW · V1.0.0 ] PUBLISHED STANDARD
BUILD IT · SHIP IT · OPERATE IT · TRANSFER ITNo one reaches the field on theory alone.
No LockedIn-qualified FDE reaches the field without candidate-owned work that was deployed to production, operated against real use, independently reviewed, and transferred with an inspectable evidence chain.
01 · MISSION ORIGINS
Real constraints. Three legitimate starting points.
A cohort can build a venture, solve a sponsor-shaped problem in a clean room, or enter a supervised client mission. All three preserve honest source custody; all three still require a real production release before the final production-experience claim.
- PC-0101
Cohort venture
A pod originates a product, earns real users, and carries it from discovery through production operation and ownership transfer.
The venture may become a real business, but participation, equity, IP ownership, and commercialization must be separately agreed before build work begins.
- PC-0202
Sponsor clean room
A real enterprise requirement is recreated with approved synthetic or minimized data and shipped in a separate environment without entering the sponsor's production estate.
The project review proves the method against authentic constraints; it never implies client acceptance, source access, or permission to reuse confidential material.
- PC-0303
Supervised client mission
A bounded client mission runs under written source custody, named supervision, client authority, and explicit retention and evidence-return terms.
Client source, data, identities, and raw evidence remain inside the contracted boundary. Only approved metadata and attestations return to the formation record.
02 · THE PROJECT REVIEW RUN
The DEPLOY method becomes a release record.
Each move ends in inspectable evidence and a stop rule. The process is not a canvas for confident narrative: if requirements, identity, source, release, operation, or transfer cannot be verified, the project review stops at that boundary.
- D01
Diagnose
What consequential workflow and user problem are we actually changing?
- Observed current-state workflow
- User and decision-owner interviews
- Constraints, assumptions, and unknowns
Stop when the problem is only a technology preference or cannot be investigated inside the approved data boundary.
- E02
Establish
What outcome, guardrail, authority, and kill condition govern the work?
- Versioned business requirements
- Acceptance and non-acceptance criteria
- Scope, identity, data, risk, and ownership contract
Stop when no accountable business owner can accept, reject, constrain, or terminate the mission.
- P03
Prove
What is the smallest repository-backed wedge that can falsify value safely?
- Traceable requirements and architecture decisions
- Working code, tests, evaluations, and threat model
- Pull-request history and disclosed AI assistance
Hold when the evaluator cannot reproduce the exact commit or when a critical requirement has no executable or inspectable evidence.
- L04
Land
Can this exact candidate move through a reversible production release?
- Pinned CI and release candidate
- Deployment, approval, migration, and rollback records
- Production smoke result and release provenance
Hold when the deployed artifact cannot be bound to the reviewed commit or rollback is not credible for the change's consequence.
- O05
Operate
Does the system create accepted outcomes while its failures remain detectable and containable?
- Health, outcome, adoption, cost, and guardrail signals
- Incident or game-day timeline
- Containment, recovery, and invalidated-gate reruns
Hold when infrastructure health is substituted for user outcome, critical failures are hidden, or no human owns the operating decision.
- Y06
Yield
Can a named owner change, recover, and explain the system without hidden FDE intervention?
- Runbook, architecture, known-limits, and escalation package
- Owner-executed change and recovery
- Permission-bounded field memo and after-action review
Hold when the handoff depends on undocumented knowledge, personal credentials, or continued access by the candidate.
03 · NONCOMPENSATING PRODUCTION MINIMUM
Production is a fact, not a confidence score.
At least one exact candidate-owned release must reach a real production environment, serve real users or operators, remain observable long enough to produce operating evidence, and carry a verified rollback or recovery path.
NONCOMPENSATING
No average, narrative, or substitute can waive it.
REQUIRED PRODUCTION EVIDENCE
- 01Exact repository and commit identity
- 02CI result and immutable build or artifact digest
- 03Production deployment record and environment identity
- 04Real-user or real-operator observation with an accountable owner
- 05Health, outcome, guardrail, cost, and incident evidence
- 06Rollback or recovery exercise
- 07Named-owner handoff and teach-back
WHAT DOES NOT COUNT
- Course completion, attendance, or watch time
- A local demo, screenshot, prototype, or unobserved preview
- A simulation or production-equivalent decision without a separate real production release
- A teammate's deployment when the candidate's decisions and ownership are not traceable
- An AI-generated score without cited evidence and independent human review
04 · TEN-GATE REGISTER
No strength elsewhere can purchase a pass.
Every gate scores at least 3, every production-minimum item is verified, no critical hold remains open, and the independent human decision is PASS.
- C01CRITICAL
- C02REQUIREDGATE 02FLOOR · 3/4
Repository craftsmanship
The exact commit shows coherent branching, reviewable changes, ownership, reproducible setup, dependency discipline, and disclosed AI assistance.
- Commit and PR history
- CODEOWNERS or owner map
- Run instructions
- C03CRITICALGATE 03FLOOR · 3/4
Architecture and interoperability
System, identity, data, model, and tool boundaries are explicit; business logic is portable and consequential crossings are owned.
- Architecture decisions
- System and data-flow views
- Interface contracts
- C04CRITICALGATE 04FLOOR · 3/4
Testing and AI evaluation
Deterministic tests, model evaluations, held-out cases, failure clusters, and rerun rules are proportionate to consequence.
- Test and eval results
- Held-out boundary
- Regression record
- C05CRITICALGATE 05FLOOR · 3/4
Security, privacy, and authority
Identity, authorization, secrets, data handling, abuse cases, retention, audit, and human control fail closed under adversarial review.
- Threat model
- Control tests
- Residual-risk register
- C06CRITICALGATE 06FLOOR · 3/4
Release integrity
The reviewed commit, CI result, build artifact, approvals, production deployment, and rollback path form one reproducible chain.
- CI and provenance
- Deployment record
- Rollback result
- C07CRITICALGATE 07FLOOR · 3/4
Operability and resilience
The system exposes meaningful health and outcome signals, bounded cost, alerts, support ownership, and tested containment and recovery.
- SLO and telemetry map
- Incident timeline
- Recovery evidence
- C08CRITICALGATE 08FLOOR · 3/4
Business outcome and adoption
Real users or operators produce an observed outcome; the record distinguishes adoption, value, guardrails, uncertainty, and the no-build alternative.
- Outcome observation
- User or operator feedback
- Decision-owner record
- C09CRITICALGATE 09FLOOR · 3/4
Ownership transfer
A named owner can operate, change, recover, and explain the system; open risk and debt retain owners and dates.
- Transfer package
- Owner teach-back
- Owner-executed recovery
- C10CRITICALGATE 10FLOOR · 3/4
Integrated defense
The candidate defends the evidence chain and adapts under a live requirement change, failure injection, and cross-functional questioning.
- Defense record
- Injected-change decision
- Independent panel verdict
0
Unrateable or unsafe
Evidence is absent, contradictory, outside the approved boundary, or exposes a critical unsafe condition.
1
Asserted
The candidate names the practice but provides no reproducible evidence that it changed the system or decision.
2
Partially evidenced
Relevant evidence exists, but material traceability, failure handling, ownership, or operating proof remains incomplete.
3
Defensible
The exact evidence supports the requirement, survives independent reproduction, and names tradeoffs, limits, owners, and recovery.
4
Production-proven
The practice held under real operation or controlled pressure, changed from evidence, and transferred without hidden dependence on the candidate.
05 · THE REVIEW STACK
The agent investigates. Humans decide.
Deterministic checks and an assessment agent may collect evidence, reproduce checks, and propose cited findings. They cannot issue qualification, waive a gate, resolve a conflict, or turn missing evidence into a pass. The current practice workbench executes R1 and R2 only; R3 and R4 remain separately governed and mandatory before a final Human Project Review decision.
- R101 / 04
Deterministic evidence collector
OWNER · Project review runnerExact commit, tree, pull requests, checks, test reports, dependency and security records, build provenance, deployment references, and content digests.
Collects facts. No score or decision authority.
- R202 / 04
Evidence-citing assessment agent
OWNER · LockedIn assessment agentGate-by-gate proposed scores, cited files and records, contradictions, missing evidence, adversarial probes, and questions for the candidate.
Advisory finding only. Never qualification authority.
- R303 / 04
Independent human review
OWNER · Authorized reviewersTwo evidence-bound decisions, visible disagreement, and separate adjudication when required.
Human gate authority under the active review policy.
- R404 / 04
Live integrated defense
OWNER · Independent panelRequirement change, failure injection, architecture and risk defense, and a unanimous evidence-bound verdict.
Final project review verdict only; professional qualification remains a separate governed decision.
Public evidence now. Scoped access when private.
The current practice workbench reads only an authorized public repository at an exact commit through fixed GitHub hosts and accepts no credential. Private or continuously connected repositories must use a selected-repository, read-only GitHub App installation—never a shared collaborator account or learner-supplied token.
READ-ONLY PERMISSIONS
- + Metadata · read
- + Contents · read
- + Pull requests · read
- + Checks · read
- + Actions · read
- + Commit statuses · read
- + Deployments · read
- + Security events · optional read when explicitly approved
NEVER GRANTED
- × Repository administration
- × Contents, branch, issue, or pull-request writes
- × Organization-wide installation by default
- × Learner-supplied personal access tokens
- × Production secrets or environment credentials
- × Autonomous merge, release, deployment, or qualification decisions
- Installation is limited to selected repositories
- Every assessment binds an exact 40-character commit SHA
- Installation tokens are short-lived and never rendered to the learner
- Webhook signatures are verified before state changes
- Repository analysis runs in a disposable no-secret sandbox with outbound network disabled by default
- Untrusted repository scripts are not executed until an allowlisted build plan is approved
- Raw client source never enters a general training corpus
PROJECT REVIEW PACK · READY TO USE
Start with evidence. End with an owner.
The pack includes mission authority, requirements traceability, repository identity, architecture, verification, production, operation, transfer, agent findings, independent review, and the integrated defense record.
Completing a pack is not a credential, license, SOC audit, accreditation, employment authorization, or guarantee. It becomes qualification evidence only through the separately governed review and decision system.