Skip to content
Inside the learning studio

Learn the tools.
Deliver together.

Developers, product managers, project managers, and forward-deployed engineers. A shared foundation, practice for your role, and work another person can use.

Start with Claude Code
Explore below · sign in to start a courseLearn → Practice → Discuss → Deliver

The formation lab · open to everyone

From AI fundamentals
to engineering judgment.

Follow one engineering decision from first principles to a defensible handoff. Try the method yourself.

Interactive case study
Step 1 of 6Find your starting point

Start with a real decision.

A fictional support team wants an assistant to search approved guidance and draft a reply. Sending a message remains a human decision.

The FDE question

Can this person explain why an apparently reasonable AI design can fail?

Try the free assessment
How this connects to the training pathway

A new hire or community visitor answers ten original architecture scenarios. The result identifies concepts to practise and recommends a first reading. It does not assign an FDE level.

Evidence: A study route ordered by the decisions the learner missed, with an explanation for every answer.

Use the result to choose what to study; confirm practical ability through later work.

L SUPPORT ASSISTANTSynthetic case
01 / REQUEST“Draft a reply”
02 / INFERENCEA proposal,
not permission.
03 / CONTROLVerify before actingIdentity → scope → approval
Human review before sending
Where should permission to send a reply be enforced?
More free learning resources and access information

Full Academy instruction and learner evidence require a provisioned training seat. Signing in alone does not grant access. This public lab keeps selections in this page only, until you leave or reload. It does not create learner records or customer outcomes.

The forward-deployed engineer

Build with the client.
Leave them able to operate.

A forward-deployed engineer (FDE) works alongside a client’s business and technical teams to understand a problem, build and evaluate a solution, integrate it into the operation, and transfer ownership. AI expertise matters alongside discovery, software engineering, security and clear communication.

Understand the operationBuild and evaluateDeploy and observeTransfer ownership

Five levels. Increasing responsibility.

These are LockedIn Labs’ training levels. Advancement requires reviewed evidence; a diagnostic score or a finished lesson does not award a level.

  1. Level 1 — cleared for access

    Understand the company, explain the AI system, and safely change a small service with guidance.

    What this level permits

    Paired work; no independent client representation.

    A floor, not a credential. Placement and the Bridge establish the route; access follows the required evidence and estate authorisation. Only a paired associate inside a pod, never the client-facing voice. No certification mark appears in this band.

  2. Level 2 — Practitioner

    Build a bounded AI service and show its tests, access controls, operating cost and discovery brief.

    What this level permits

    Own a defined engineering task with review.

    A first Java AI service, evaluated, secured and priced behind a provider boundary, with a discovery brief.

  3. Level 3 — Operator

    Integrate systems, investigate failures and defend decisions under changed constraints in assessed simulations.

    What this level permits

    Demonstrate production behavior in rehearsal.

    C1, one twin and three assessed simulations; production behaviour proved in rehearsal across two providers.

  4. Level 4 — Forge-passed

    Deliver an integrated team engagement and pass independent technical and business review.

    What this level permits

    Represent the work to a client under a lead.

    Four weeks in a pod under pressure. Two independent assessors and technical and business signers clear client representation under a lead.

  5. Level 5 — Elite

    Prove a real delivery outcome, transfer ownership and defend the evidence before an independent panel.

    What this level permits

    Field-proven delivery; course completion alone is insufficient.

    Field evidence, ownership transfer and an independent integrated defence. A course duration cannot confer this standing.

How the pathway relates to industry standards

The role definition draws on AWS’s embedded delivery model, including customer ownership after delivery. SFIA provides a useful lens for increasing autonomy, influence and complexity. SFIA has seven responsibility levels; our five training levels are not a numbered equivalence or an SFIA certification.

NIST’s AI Risk Management Framework informs risk-aware practice. Referencing it does not certify an engineer or establish compliance. Sources reviewed 4 October 2026.

The ladder describes the assessment design. Current qualification issuance and its prerequisites are documented in the qualification standard.

Start the free assessment
01 · Role to delivery

Different roles.
One useful outcome.

A pod is a small team working on a shared mission. See what each person practices and how their work connects.

Choose how you practice
Your contribution to the team

Build and verify the slice

Build useful AI features and show that they behave as intended.

Produce something useful

Create the bounded workflow, test correct and misleading requests, and show source checks, human escalation, and reproducible run instructions.

See this learning path
One shared mission

Build an internal support assistant

A fictional support team wants help routing requests and drafting answers. Use synthetic tickets and a small invented knowledge base. The assistant must cite its source, recognize uncertainty, and hand difficult cases to a person.

  1. Product managerDefine a useful outcome
  2. Project managerMake the work deliverable
  3. DeveloperBuild and verify the slice
  4. Forward-deployed engineerHand it to the operator

This is an illustrative training mission. Role cards describe responsibilities; they do not assign teammates, schedule a meeting, or record completed work.

02 · Watch, then do

A short lesson.
A decision to make.

Try this 90-second lesson on giving AI a clear task. Watch with captions, follow the transcript, then practice a decision.

FIELD LESSON · ACTUAL MEDIA1:30 · CAPTIONS + CHAPTERS

Prompting as specification — a 90-second operator lesson

Prompts are programs in natural language. Write them with intent, context, constraints, and acceptance tests.

Open MP4 ↗1280 × 720 · H.264 / AAC
Chapter runway
  1. 01Vibes vs specs
  2. 02Control the input
  3. 03Constraints and output contract
  4. 04Failure behavior
  5. 05Evaluate the specification
  6. 06Produce evidence
WATCH → READ → BUILD → PROVE

Playback never completes this node. Continue through the full briefing, operating workshop, artifact submission, and published review rubric.

Read the exact 90-second transcript

01A prompt used once can survive on vibes because a human catches the weirdness.

02The same prompt inside a workflow needs a specification: explicit inputs, behavior, limits, and a way to fail safely.

03Start with context you control. Paste the source material, name the audience, and define the task with one clear verb.

04Never make the model invent the information that your workflow should supply.

05Turn expectations into numbered constraints, then define an output contract the next step can parse.

06A schema beats a pleasant paragraph because structure makes success testable and drift visible.

07Now specify failure behavior. If evidence is missing, say so. If the request crosses a policy boundary, stop.

08A production prompt needs a safe result for impossible work, not confident improvisation.

09Run the same prompt against a small test set: normal cases, edge cases, and one adversarial input.

10Compare results against the contract. Revise the specification, not just the single bad answer.

11Your evidence is the before prompt, the production specification, the test inputs, and the observed outputs.

12Submit that package for review. That is the loop: operate, verify, prove, then advance.

This is an existing LockedIn Labs lesson. Watching this public preview does not record course completion.

03 · Learning that gets used

See it. Try it.
Talk it through.

Combine demonstrations, practice, discussion, feedback, and later challenges. Every learner produces their own evidence, including when the team works together.

  1. 01

    See an example

    Follow a worked example. Notice the decision, the result, and the mistake the practitioner corrected.

    Short demonstration, diagram, and written explanation
  2. 02

    Try it yourself

    Solve a related task. Use AI to assist, check the output, and keep a record of what you corrected.

    Guided practice and a role-specific artifact
  3. 03

    Explain your decision

    Take a position first. Discuss the evidence with a peer, then explain what changed in your reasoning.

    Board discussion or a facilitated conversation
  4. 04

    Make a handoff

    Give the next role enough context to use your work. Let their attempt reveal what is missing.

    Pod exercise or structured individual simulation
  5. 05

    Use the feedback

    Compare your work with the criteria, make a correction, and show the difference between attempts.

    Rubric feedback and a revised artifact
  6. 06

    Apply it again

    Recall the method before reopening the lesson. Use it on a changed scenario a few days later.

    Recall prompt and a fresh challenge
See a sample cohort week

An example cadence to agree with a facilitator when a cohort is scheduled.

  1. Monday

    Understand the challenge

    Open the week's outcome, study one example, and predict its failure point.

    Bring: A starting decision and the question you need to answer
  2. Tuesday

    Build your contribution

    Complete the practice for your role. Record the AI assistance you used and how you checked it.

    Bring: A first artifact and one observed result
  3. Wednesday

    Discuss and challenge

    Post a focused feedback request or join the facilitator's arranged discussion. Explain a decision before comparing answers.

    Bring: A question, a response, and your revised reasoning
  4. Thursday

    Connect the work

    Hand your contribution to the next role. Test whether they can use it without guessing.

    Bring: A receiver's readback and a corrected handoff
  5. Friday

    Show the improvement

    Demonstrate the result, act on rubric feedback, and record your next step.

    Bring: A revised artifact and a short reflection
  6. Next week

    Transfer the skill

    Explain the method from memory, then apply it to a changed situation.

    Bring: An individual answer and a fresh attempt

Use community boards for written discussion and feedback. Facilitators arrange live meetings in an agreed meeting tool; native calls and video rooms are not active.

Explore cohort formats →
Why this approach supports learning

Worked examples, retrieval practice, spaced challenges, peer discussion, and specific feedback inform this design. Different formats make the material accessible and give people multiple ways to engage. We do not assign people a fixed visual or auditory learning style. The research supports these methods; program outcomes still require measurement.

04 · Add the right provider skills

Learn from the source.
Apply it to real work.

Use official training alongside role practice. Providers control their courses, exams, eligibility, and awards.

Compare all provider pathways and credentials →

Official courses open on the provider’s site. A completion badge, a provider certification, and a LockedIn Labs credential represent different evidence. Licensed third-party training is not included unless rights are agreed.

Bring a real team challenge

Start with the people.
Build around the work.

Choose the roles, identify one useful outcome, and agree the cohort, facilitator, and evidence needed for a bounded pilot.

Plan a team pilot

Public previews demonstrate the learning design. Live cohorts and staffed review need agreed operating arrangements. The FDE pathway remains the advanced engineering specialization.

Explore the engineering tools and evidence controls
Field standard
FDE-S/1.0 · authored

One mission method, six stage exits.

A forward-deployed engineer converts an ambiguous, consequential workflow into an adopted production system inside the customer's operating constraints, proves its behavior, transfers ownership, and returns reusable learning to the product without binding the solution to one model or interface.

Forward-Deployed Engineering Standard

Forward-Deployed Engineering

Diagnose the work. Establish the outcome contract. Prove the smallest wedge. Land inside the enterprise. Operate from evidence. Yield ownership and compound learning.

VERSION
1.0.1
BAND
L2 → L4
MODULES
8
EVIDENCE GATES
10
  1. D01 / 06

    Diagnose

    How does the work actually move, especially where the documented process breaks?

    PRIMARY EXIT SIGNALMission charter, stakeholder map, and observation boundary

  2. E02 / 06

    Establish

    What is the smallest safe wedge that can produce decision-grade evidence of workflow impact?

    PRIMARY EXIT SIGNALOutcome contract and wedge decision record

  3. P03 / 06

    Prove

    Can the smallest wedge meet the mission contract under representative, edge, adversarial, and changing conditions?

    PRIMARY EXIT SIGNALRunnable wedge and provider-neutral behavioral contract

  4. L04 / 06

    Land

    Can the proven wedge live inside enterprise identity, data, control, and operating boundaries without losing its evidence?

    PRIMARY EXIT SIGNALProduction-shaped enterprise integration slice

  5. O05 / 06

    Operate

    Can users adopt the system while the team detects, contains, and learns from behavior in production?

    PRIMARY EXIT SIGNALProduction-readiness and staged-rollout record

  6. Y06 / 06

    Yield

    Can the named owner operate, change, and recover the system—and what permitted learning should compound?

    PRIMARY EXIT SIGNALOwner-accepted transfer package and owner-executed change/recovery record

Actual lesson
1:30 · 6 chapters

Return to the lesson demonstration.

The lesson above includes the MP4, English captions, chapter track, and transcript. Playback creates no completion event.

Return to the lesson
Runtime X-Ray
AUTHORED EXECUTION MODEL

Reveal what the terminal hides.

Step through the model proposal, control decision, machine action, and evidence return. Play the authored trace or branch into a denied action; neither control executes a command.

RUNTIME X-RAY · 101 L1 · N-L1-1
RUNTIME X-RAY · AUTHORED TRACE

One task becomes an accountable workflow

Move left to right through the work the screen compresses into a few status lines: inputs are gathered, context is shaped, a model proposes, checks hold the boundary, and a person authorizes the exit.

NO LIVE RUNTIME

Authored simulation — this is not a live trace. It does not inspect your terminal, editor, agent runtime, files, prompts, or learner activity.

INSTRUCTION / SYNTHETIC
READ-ONLY LEARNING INSTRUMENT

Build the weekly partner update from the approved metrics file. If any required metric is missing, stop before drafting. Never publish without my review.

THREE PLANES / ONE ACCOUNTABLE LOOP

The model proposes. The control plane scopes and authorizes. A tool or service executes, then returns inspectable evidence.

MODEL → MACHINE · NO DIRECT PATH
P-01

MODEL PLANE

PROPOSES

Workflow · Model

P-02

CONTROL PLANE

SCOPES + AUTHORIZES

Operator

P-03

MACHINE + EVIDENCE

EXECUTES + RETURNS

Tools + runtime · Evidence

EXECUTION TRACE

Select a transition. Arrow keys move through the authored run.

Stage 1 of 8: Capture the trigger. You choose RUN UPDATE.

STAGE 01 · Operator

Capture the trigger

INSPECTING EVENT
WHAT YOU SEE

You choose RUN UPDATE.

WHAT HAPPENS BEHIND THE GLASS

The workflow creates a run identifier and freezes the task contract for this execution.

INPUT BOUNDARY

Operator intent + approved workflow definition

OUTPUT / STATE CHANGE

Run envelope with named exit and stop condition

WHO OR WHAT HAS AUTHORITY

The operator starts this defined workflow; neither the model nor a tool can create its own run.

WHAT PROVES IT

Run id, actor, start time, workflow version

FAILURE REPLAY · RETURN TO DECISIONAT VERIFY-CONTRACT
SYMPTOM
The draft fluently explains a sharp decline even though one metric row never arrived.
HIDDEN CAUSE
The source read succeeded, but completeness was not checked before generation; fluent output hid a partial input.
CONTAINMENT
The required-metric check blocks the human gate and the action tool remains unreachable.
HUMAN DECISION
Repair the source, replay from gather, and compare both run logs before changing the gate.
CURRENT KNOWLEDGE RUNWAY

Go from mental model to field command.

Maintained specifications, official runtime guides, and open-source implementation references, checked through 2026-10-21. Each entry records its currency signal and next recheck deadline; links are learning references, not claims about this platform's runtime.

101 · SEE THE LOOP
  1. OPEN SOURCE· MIT (software)
    Running agents (opens in a new tab)

    OpenAI Agents SDK · Follow the work between a user prompt, model turn, tool result, and final output instead of treating the terminal spinner as the system.

    The current TypeScript SDK guide covers the run loop, turn boundaries, state, streaming, and resumable execution.

    REVIEWED 2026-08-27 · RECHECK 2026-11-27

OPERATOR · CONTROL THE LOOP
  1. OPEN SOURCE· MIT (software)
    Human in the loop (opens in a new tab)

    OpenAI Agents SDK · Place explicit human authority before consequential tools, preserve paused state, and make rejection a designed path.

    The current SDK supports interruptions, approval decisions, rejection, and resuming a serialized run state.

    REVIEWED 2026-08-27 · RECHECK 2026-11-27

  2. OFFICIAL REFERENCE
    Automate workflows with hooks (opens in a new tab)

    Anthropic Claude Code · Map the invisible event lifecycle around a visible tool call and identify where deterministic checks can run before or after agent action.

    The current lifecycle exposes session, prompt, pre-tool, permission, post-tool, subagent, stop, task, and compaction events across terminal, IDE, desktop, and web surfaces.

    REVIEWED 2026-08-27 · RECHECK 2026-11-27

METHOD BOUNDARY · Selecting, replaying, or reading this specimen never completes a node, submits evidence, contacts an external system, or changes learner state.
Operator Trial
PRACTICE-ONLY · NO ACCOUNT WRITE

Make one consequential decision.

Choose a role target and respond to a release trace that looks healthy in aggregate but fails a required case. The interpretation explains the evidence boundary; it does not score you.

AUTHORED SPECIMEN · operator-trial/v1IDENTITY NOT REQUESTED · NO ACCOUNT WRITE
  1. 01ROLESELECTED
  2. 02DECISIONOPEN
  3. 03INTERPRETPENDING
  4. 04RECORDNOT CREATED
STEP 01 · ROLE TARGET

Which work should this decision protect?

These are the three existing Role Application Atlas targets. The standard stays fixed. Selecting one changes the required floors, evidence, and next route—not the scenario and not a measurement of you.

Choose an authored role target
TARGET BAR

Verification & quality control · 3/4

AUTHORED GATE

22 dependency-closed nodes

PROOF MODULE

The enterprise AI control plane

Why this control matters: Defends the delivered system with task tests, observability, and an operational response to failure.

STEP 02 · OPERATING DECISIONBME-09 · SYNTHETIC

The aggregate looks healthy. The trace does not.

A candidate clears five routine cases. The required sixth case shows a critical trajectory failure: after a customer explicitly asks for a person, the agent argues and continues the automated reply. The exact-candidate suite also omits that required case. Delivery asks to release today. What happens next?

Inspect the authored packet boundary
  • Unit, trajectory, and outcome are separate mandatory gates. A passing aggregate cannot average away a critical trajectory failure or missing required case.
  • Record HOLD before changing the failed candidate, then invalidate and rerun every gate controlled by a patched file.
  • The deterministic simulation never opens a shell, contacts a model or network, sends a response, or changes a customer or production system.
Choose the next release decision

Choose the next action. The interpretation compares the selection with the published lab contract; it does not infer capability from one answer.

This authored specimen interprets one selected decision against the published BME-09 control sequence. It is not a capability assessment, learner record, credential, hiring signal, or evidence that the workflow was executed. A linkable view carries only the selected role and decision IDs in its URL; it does not write them to an account.

Evidence Chain
ASSESSMENT → GRAPH → WORK → REVIEW → RECORD

Follow the claim back to its evidence.

The public Evidence Chain uses current assessment, graph, field-exercise, review, and registry contracts. Protected stages link to their public explanations here, never to a learner record.

EVIDENCE CHAIN · SYSTEM VIEW
The complete static evidence model is active. Three-dimensional enhancement is available.
INPUT · WORK SIGNALOUTPUT · PUBLIC RECORD
BME-01 · n-l3-59 NODE ROUTE
03SELECTED PLANE
Public packet briefProvisioned workbench

Hold or ship the support agent

BME-01 maps to n-l3-5 and publishes 4 synthetic packet sources with 4 weighted rubric dimensions.

4rubric dimensions
  1. 01 · assessment

    Capability assessment method

    Open public detail →
  2. 02 · graph

    Authored skill graph

    Open public detail →
  3. 03 · benchmark

    Hold or ship the support agent

    Open public detail →
  4. 04 · review

    Artifact review

    Open public detail →
  5. 05 · registry

    Certified AI Native Developer

    Open public detail →
ISOLATED SPECIMEN · NOT CUSTOMER OR LEARNER DATAPublic · read-only
ENTERPRISE GOLDEN THREAD PRESENTER-RUN SPECIMEN

One operating story. Every boundary stays in frame.

Trace how an enterprise operator reads aggregate formation state, hands the camera to a practitioner, and inspects a bounded field lab—without borrowing a customer identity or fabricating a credential, receipt, or outcome.

Each frame mirrors a shipped interface contract. The values below are an authored presentation, not production Store rows.

A facilitator cannot follow a roster row into a learner’s journey, Atlas, artifact, or review. The presenter changes lenses here. No account is impersonated.

PRESENTER TIMECODE

Ten minutes, sequenced for evidence.

00:00 → 10:00
  1. T+00TRUTH

    Perspective · Presenter

    Establish the specimen boundary

    State that every value is an authored presentation, never customer or learner data.

  2. T+01OPERATIONS

    Perspective · Enterprise operator

    Read the program state

    Confirm one anonymous sample seat, its recorded sample baseline, and the reporting boundary.

  3. T+03HANDOFF

    Perspective · Presenter

    Change lenses without impersonation

    Move from aggregate operations to the anonymous specimen without opening a roster row or learner account.

  4. T+04JOURNEY

    Perspective · Anonymous specimen

    Follow the evidence route

    Trace the sample from activation through a required evidence revision without entering a learner account.

  5. T+06ATLAS

    Perspective · Capability lead

    Inspect the FDE progression

    Read all eight authored modules and the prerequisite graph behind the sample state.

  6. T+08LAB

    Perspective · Practice evaluator

    Open the lab standard

    Inspect the six-stage BME-10 practice loop and the evidence expected at every stage.

  7. T+09CONTINUE

    Perspective · Enterprise sponsor

    Choose the next public path

    Continue to the public trial, lab catalog, or a sales-assisted enterprise conversation.

OPERATIONS SPECIMEN

Read aggregate state before opening a story.

SPECIMEN-01

These four bounded states establish what an enterprise operator can discuss without opening a person-level record.

Seat posture
Active sample seatactive sample
Baseline
Baseline recorded · samplerecorded sample
Reporting
Aggregate reporting remains privateaggregate private
Outcome posture
Individual outcomes withheldwithheld
LEARNER JOURNEY · PRESENTATION STATE

Follow the evidence, not a borrowed account.

Five authored waypoints explain how practice becomes reviewable. They display specimen state only and cannot advance a graph, create a receipt, or grant a credential.

  1. 01Active sample
    SEAT

    Sample seat active

    The specimen begins with one explicitly labeled sample seat, not an enrollment claim.

  2. 02Recorded sample
    BASELINE

    Sample baseline recorded

    A baseline state is shown as recorded without exposing answers, dimension scores, or an assessment record.

  3. 03Route assigned
    ROUTE

    FDE route assigned

    The specimen follows the current eight-module authored FDE route and its real graph joins.

  4. 04Revision required
    REVISION

    Evidence revision required

    The third module remains open for revision; the public view does not invent a score or reviewer decision.

  5. 05Not created
    RECEIPT

    Practice receipt not created

    BME-10 remains an inspectable practice contract. No artifact, review, qualification, credential, or receipt is created here.

FDE CAPABILITY ATLAS · EIGHT MODULES

Two complete. One in repair. Five stay closed.

Statuses describe SPECIMEN-01 only. They do not alter curriculum progress, unlock a module, or establish FDE readiness.

Nodes
49
Edges
58
Levels
5
FDE modules
8
  1. Sample complete97 min
    FDE-01

    Diagnose the work, establish the outcome

    Sample evidence is shown complete in this isolated view.

    Sample complete
  2. Sample complete87 min
    FDE-02

    Scope and architect the mission

    Sample evidence is shown complete in this isolated view.

    Sample complete
  3. Revision required103 min
    FDE-03

    Land inside enterprise systems

    The specimen must revise its evidence before advancing.

    Revision required
  4. Locked · inert109 min
    FDE-04

    Engineer provider-portable AI systems

    Locked until the preceding sample evidence clears.

    PREREQUISITES REQUIRED · INERT
  5. Locked · inert114 min
    FDE-05

    Operate an evaluation and reliability control system

    Locked until the preceding sample evidence clears.

    PREREQUISITES REQUIRED · INERT
  6. Locked · inert102 min
    FDE-06

    Bound authority and earn authorization

    Locked until the preceding sample evidence clears.

    PREREQUISITES REQUIRED · INERT
  7. Locked · inert119 min
    FDE-07

    Operate adoption, rollout, and incidents

    Locked until the preceding sample evidence clears.

    PREREQUISITES REQUIRED · INERT
  8. Locked · inert103 min
    FDE-08

    Yield ownership and compound field learning

    Locked until the preceding sample evidence clears.

    PREREQUISITES REQUIRED · INERT
FIELD LAB SPECIMEN BME-10 · V1.1.0

Run the forward-deployed field loop

The public tour exposes only safe authored stage labels and evidence descriptions. It does not expose the runtime packet, learner response, evaluator material, artifact, or receipt body.

Lab window
75min
Evidence mode
practice-only
  1. 01discover

    Discover

    EVIDENCE PRACTICED

    Workflow map plus baseline/value hypothesis with stakeholder, constraint, and unknown boundaries.

  2. 02frame

    Frame

    EVIDENCE PRACTICED

    Architecture decision record, acceptance gates, two-week sequence, and named responsibility map.

  3. 03build

    Build

    EVIDENCE PRACTICED

    Server-bound authorization, citation checks, bounded retries, protected traces, and flagged rollback.

  4. 04deploy

    Deploy

    EVIDENCE PRACTICED

    A HOLD, repaired candidate, current gate reruns, 24-user read-only canary, and rollback authority.

  5. 05recover

    Recover

    EVIDENCE PRACTICED

    Inspection, pause, preservation, safe-scope language, tombstone repair, and affected-gate reruns.

  6. 06handoff

    Handoff

    EVIDENCE PRACTICED

    Runbook, SLO, kill switch, owners, evidence location, teach-back, adoption backlog, and reusable field signal.

LAB RECEIPTnot created · presentation only
Protected system
AUTHORITY MAP · NO PRIVATE PROJECTION

The tour ends where identity begins.

This final map shows how the implemented learning, evidence, formation, session, support, and operating contracts connect. It deliberately contains no person, cohort, scheduled offering, post, seat, or artifact.

LEARNINGPROVISIONED

Path, courses, and labs

A signed-in account can hold an assessment and path. Full lessons and workbenches open only when the relevant training is provisioned.

AUTHORITY PRESERVED
EVIDENCEOWNER BOUND

Owned artifacts and revision

Submission, review history, and portfolio state stay attached to the owner. The public tour receives none of those records.

AUTHORITY PRESERVED
FORMATIONENROLLMENT BOUND

Cohort and working board

Private rooms resolve from active enrollment. Commons, cohort posts, replies, and evidence attachments retain their existing server authority.

AUTHORITY PRESERVED
SESSIONSSEAT BOUND

Preparation and calendar handoff

The implemented flow binds seat authority, canonical prework, a provider-neutral calendar handoff, an owner-bound brief, and an authorized board. No scheduled offering or participant state appears here.

AUTHORITY PRESERVED
SUPPORTACTIVATION GATED

AI mentor and human boundary

AI concept, specification, and next-step support is separate from human review or expert intake, which remains fail-closed until its operating coverage exists.

AUTHORITY PRESERVED
OPERATIONSROLE GATED

Tenant and decision controls

Enrollment, moderation, organizational, and review decisions remain role-gated and actor-bound. A tour interaction grants no authority.

AUTHORITY PRESERVED
PRESENTER CONTINUATION · PUBLIC

Choose the next lens.

Continue as an individual practitioner, an organization building an internal cohort, or a diligence reader inspecting the evidence. Identity remains required only for protected learner work. This system map describes implemented and gated product contracts. It contains no learner, tenant, enrollment, artifact, community, session, attendance, staffing, review, or credential record.