The Standard of Record is a forward-deployed engagement method: reconstruct the engineering practices your organization already trusts, ratify them into a standard you own, make that standard executable, and measure the same people on one unchanged capability instrument before and after the work.
No engagement has run under this method. Delivery activates only under signed scope; running platform capabilities are labeled below.
On signed scope, engineers would embed inside your organization on your approved stack.
Candidate workflows would move through your production authorization gates.
Roadmaps and AI-native training plans would be scoped role by role.
The handoff gate would require your people to operate what was approved and built.
This is the buying view: what each phase must leave behind, what can be inspected before signature, what begins only inside a signed engagement, and what your team must supply for the work to be valid.
Every ledger line traces to source history, named client ratification, or the unchanged published capability instrument.
Every roadmap item traces to a ratified practice and a measured capability dimension; unsupported opinion is removed.
The approved gate rejects a build that violates a ratified practice and passes one that does not.
The workflow runs in the approved environment and the named internal owner can modify it without LockedIn.
The same participant completes the same instrument twice, and a named owner accepts the client-specific handoff.
The Practice Ledger, starter repository, client review rubric, engagement playbook, and delta report transfer to the named client owner with the agreed rights to operate, modify, extend, or hand those client-specific deliverables to another implementer.
LockedIn retains its pre-existing platform, shared instrument, generic curriculum, and reusable method. Client source and evidence are not reused outside the engagement without separate written permission.
A proposed, activation-gated enterprise engagement that would turn ratified engineering practice into executable gates, reviewed work, and a client-owned handoff.
This page names the proposed operating contract. It does not represent an active, staffed, scheduled, priced, or delivered engagement.
PRACTICE LEDGER + CAPABILITY BASELINE
Every ledger line traces to source history, named client ratification, or the unchanged published capability instrument.
SEQUENCED PLAN, PRICED AS MILESTONES
Every roadmap item traces to a ratified practice and a measured capability dimension; unsupported opinion is removed.
STARTER REPOSITORY + CLIENT REVIEW RUBRIC
The approved gate rejects a build that violates a ratified practice and passes one that does not.
REVIEWED ARTIFACTS + ONE PRODUCTION WORKFLOW
The workflow runs in the approved environment and the named internal owner can modify it without LockedIn.
PUBLISHED DELTA + OWNED STANDARD
The same participant completes the same instrument twice, and a named owner accepts the client-specific handoff.
Not approved · set only in signed scope
Not approved · set only in signed scope
Not approved · set only in signed scope
Named executive sponsor
An accountable sponsor can approve the operating objective, decision boundary, and success criteria.
Named engineering authority
Senior engineers can ratify recovered practices and accept or reject the client-specific standard.
Named internal owner
One owner can accept the production workflow and operate the client-specific handoff without LockedIn.
Critical practice is tacit
Delivery knowledge lives in repositories and senior engineers but is not yet an explicit, ratified operating standard.
Capability must be measured comparably
The organization needs a fixed baseline and reassessment rather than attendance, adoption, or self-reported readiness.
The handoff must remove dependency
The client needs executable gates, reviewed work, and an internal owner—not a permanent implementation dependency.
Nominated repositories
REQUIREDNamed repositories and a written access, processing, retention, egress, and deletion boundary.
Senior engineering ratification group
REQUIREDNamed senior engineers empowered to ratify the Practice Ledger line by line.
Participant and technology scope
REQUIREDA named participant cohort and approved model, cloud, data, security, and review constraints.
Production workflow owner
REQUIREDA named internal owner accountable for the approved workflow, acceptance decision, and handoff.
Tell us the operating constraint below. The request enters the existing manual enterprise queue; it does not reserve staffing, approve data access, create scope, or grant a response time.
Boundary · public structure only. No engagement, price, schedule, staffing, source access, delivery, or outcome exists until approved in a signed operating contract.
Inspect what is already runningCapability investment can leave learning recognition without inspectable application, or a roadmap whose operating method remains dependent on an outside implementer. This proposed engagement is designed against both failure modes and is named for what the signed scope would require it to leave behind.
Every claim below carries one of three labels. Nobody who buys capability for a living should have to guess which parts of a method are software that exists and which parts are a promise about people.
In the platform now. A free signed-in account can run the assessment; provisioned learners can submit eligible artifacts for review. Public evidence contracts are inspectable before an enterprise signs anything.
Work done by people inside your organization. It does not exist as a product surface and starts when an engagement starts.
A commitment in the engagement document — an obligation we take on, enforceable by you, not a feature we shipped.
No engagement has been run under this method. There is no pilot, no outcome data, and no client to reference. Paid enrollment is in preview and no revenue has been transacted. The labels are the whole disclosure — what runs today runs today, and what starts on signature says so.
Two independent instruments, deliberately not merged. One reads the organization. One reads the people. The finding is the distance between them.
DELIVERABLE · PRACTICE LEDGER + CAPABILITY BASELINEAcross three to four repositories you nominate, git history is read to reconstruct how your strongest engineers actually build, test, recover, and release — the practices that survive an incident, not the ones written on a wiki page nobody opens. Every recovered practice is then classified, and the classification is not ours to make: a named senior group inside your organization ratifies it line by line. What comes out is the Practice Ledger — your engineering standard, written down, with the disagreements recorded rather than smoothed over.
Chosen, defended, and worth enforcing.
Inherited from a framework or a tool. Nobody in the room chose it.
Correct in one service and wrong in the next. The rule is the condition, not the practice.
True once. Still enforced. No longer load-bearing.
The instrument that runs on this platform today: 15 authored criteria rolling into 6 capability dimensions, each scored 0–4 against evidence the person supplies — a real prompt, an agent brief, a recurring workflow they own. Every dimension is observed by at least two criteria, so one lucky sentence cannot carry a dimension. Assessments are exercises people sit down and do, not monitoring. The output is one individual baseline. The platform stores those records per person; it does not currently emit a cohort assessment aggregate.
An instrument that scores you against a standard it also wrote is a closed loop, and closed loops always report success. The forensics describe the organization. The assessment describes the individual. Merging them would erase the only reading that matters.
The diagnosis is not either instrument on its own. It is the gap between them.
DELIVERABLE · SEQUENCED PLAN, PRICED AS MILESTONESWhat your strongest engineers demonstrably do, set against what each individual can articulate and direct. The gap names two different problems at once: which ratified practices exist only in the heads of the people who invented them, and which capability dimensions have to move before the rest of the organization can hold the standard. One is a documentation and tooling problem. The other is a training problem. Most programs are sold as the second without ever testing for the first.
The sequence follows work your organization has already committed to ship. Each phase on this page is an invoice milestone with a named deliverable and an acceptance condition, so procurement and engineering review the same document rather than two translations of it.
A standard that cannot fail a build is a wiki page. A client review rubric must score client work without rewriting the fixed baseline instrument.
DELIVERABLE · STARTER REPOSITORY + CLIENT REVIEW RUBRICThe ratified ledger is encoded where it can stop work: agent instruction files, guardrails, CI checks, PR templates, and ADR and specification templates. From that point the standard is enforced by the pipeline instead of remembered in review by whoever happens to be on the PR.
The 15-criterion capability assessment remains unchanged so a person's before-and-after records stay comparable. Separately, engagement work turns the ratified Practice Ledger into a review rubric for client artifacts and build gates. That client-specific rubric is a delivered method, not a configurable product surface in the platform today, and it cannot be written before the ledger exists.
Context files tell an agent how to operate inside a repository. A review rubric names the evidence a human or automated check must see before the work passes. An engagement can deliver both, but they serve different purposes, and neither replaces the unchanged capability assessment used for the before-and-after comparison.
On an engagement, participants work against your backlog rather than a vendor-invented capstone.
DELIVERABLE · REVIEWED ARTIFACTS + ONE PRODUCTION WORKFLOWParticipants work items the organization already intends to ship, under the constraints that actually apply — the approved stack, the review path, the risk owner. A capstone written by the vendor tests the vendor's imagination of your environment.
Submission, review, verdict and in-review credential issuance for currently issuable specifications are running code. A live model pass or a human expert pass can verify an artifact and open its node; the record identifies which performed the review, and an offline heuristic cannot verify. Making a credential active remains a separate human decision. FDE-P remains planned and cannot issue or activate from graph completion.
13 field exercises are authored and running today. Each is a decision made under incomplete information and defended in writing — hold or ship, contain or escalate. The participant can read the published rubric; the held-out scoring key remains server-side and is never sent to the client.
One agentic workflow moves through evaluation, controls, deployment and adoption with your team on the change rather than copied on it. The named internal owner is identified in this phase, not at the handover meeting.
The engagement ends with two distinct records: what moved on the unchanged capability instrument, and the client standard handed over for continued use.
DELIVERABLE · PUBLISHED DELTA + OWNED STANDARDOn an engagement, every participant sits the same instrument again. The running profile comparison accepts only records scored on the same instrument and scored live, then reports per-dimension movement from first to latest. Records failing either test are excluded and named rather than quietly averaged in — so a flat profile says which it is: the person did not move, or we could not honestly measure it. Zero is a real result.
Publication is written into the engagement before the baseline is taken. We do not get to read the result and then decide whether it was a finding. A method that can only report good news is not measuring anything.
The client owns its Practice Ledger, starter repository, client review rubric, and playbook, and can modify them, extend them, or hand them to another implementer without asking us. LockedIn retains its pre-existing platform, shared capability instrument, generic curriculum, and reusable method. Client source, artifacts, and evidence are not reused outside the engagement without separate written permission.
The same people, the same fixed instrument, twice — plus the artifact reviews and field-exercise attempts recorded in between. Once participant accounts are attached to the organization, an engagement report can aggregate their separate store-backed records. The claim at the end is a comparison, not an adjective.
The client-specific ledger, review rubric, starter repository, and playbook are reconstructed from your repositories, ratified by your senior engineers, executable in your pipeline, and yours after we leave. The end condition is that operating your standard does not require us.
Both outcomes are engagement terms, not product claims. The first client under this method will be told they are the first.
The training platform has no enterprise repository connector or designated client-source ingress workflow. A future Standard of Record engagement would cross that boundary only after the approved repository, handling controls, and accountable owners are named in writing.
The current application implements neither a client-repository connector nor a designated enterprise source-ingress or retention workflow. Learner evidence fields can contain user-submitted project work; they are not an approved client-source channel and must not be used to submit client source.
Before any approved repository is opened, written scope must name every control below. None is inferred from platform access or a general services agreement.
Processing location
Authorized people and systems
Retention and deletion window
Egress rules
Subprocessors and providers
Incident and termination handling
No enterprise engagement is active and no designated client repository is connected through this product. This public surface neither creates an engagement source record nor characterizes existing learner-submitted content.
If an engagement is later signed, client source and client artifacts are not reused outside that engagement without separate written permission.
This boundary does not activate organization outcomes, cohort aggregates, or employer reporting. Those paths remain withheld.
A serious inquiry begins with scope and source custody—not a repository link.
On a signed engagement, the team would cross enterprise seams, stay close to named client owners, and move an approved roadmap toward an operating system the client can run. No delivery under this method has occurred yet.
A signed program would establish shared operating language for the people who use, govern, buy, and supervise AI-enabled work.
Product and strategy participants would frame value, redesign the workflow, sequence adoption, and keep the human operating model attached to the technology.
Builders would work across the cloud, data, security, database, evaluation, and product seams around the model.
The delivery team would embed with the client, work the interfaces between teams, move approved work through real constraints, and transfer the operating method before handoff.
A signed program would start by reading how each role works at baseline. Each participant would sit the individual assessment — how they prompt, how they direct agents, how they decompose their recurring work — and an engagement team can use those individual records when it proposes a cohort design. The platform does not currently aggregate assessment scores or assemble cohorts automatically. Assessments are explicit exercises people sit down and do, not monitoring.
The work succeeds at the interfaces. Each scoped program would make the whole approved environment visible, even when a learner specializes in only one layer.
The team would identify the workflow, constraint, owner, and evidence bar.
The team would work inside the approved client environment with product, risk, data, and operations.
One approved workflow would move through evaluation, controls, deployment authorization, and adoption.
The team would document the system, run the agreed training plan, and test whether the capability can be operated internally.
Portable specifications, compared in an approved environment.
The curriculum teaches portable prompt specifications, golden-set design, and comparison methods across model families. LockedIn does not bundle Claude, OpenAI GPT, Gemini, or other model runtimes. Learners use model access they or their organization supply. On a signed engagement, any cross-model comparison would run only inside the client-approved environment; if only one model is available, the work cannot be described as a completed cross-model comparison.
A signed program would use the same individual assessment and require reviewed work at each gate. The platform does not yet produce a cohort assessment aggregate; an org coverage view begins with separate store-backed operator records only after accounts are provisioned to that organization. Program composition, staffing, schedule, and controlling terms are confirmed in signed scope.
The shared baseline: mental models, tool literacy, prompting as specification. A signed program would put every participant through the same authored modules so roles can use one operating language.
Opportunity framing, workflow design, model behavior, adoption, and measurable value — so product and strategy teams lead the work instead of handing it off.
Spec-driven development, agentic TDD, evals, observability, and production-system design across the model, cloud, data, and security stack.
Engineers who can enter the client environment, map the real constraint, ship across the approved stack, document the system, and transfer capability.
Two half-days for C-suite and transformation leaders: honest economics, operating models, governance that ships instead of stalls.
PHI guardrails, staged validation, clinician-in-the-loop gates. AI-native practice where mistakes are regulated, not just embarrassing.
The organization surface records participation and attributable operations. It does not turn a learner’s work into an employer dashboard. Individual evidence stays private, and every outcome aggregate stays closed until the full privacy window is activated.
This instrument describes the release boundary itself. It reads no organization, roster, count, score, or outcome from runtime state.
Scores, levels, responses, exercise text, and named evidence stay outside the facilitator view.
Membership role, participation state, sharing preference, and attributable operating history are available to an authorized facilitator.
The runtime returns no organization outcome values until the privacy window and consent gates are implemented.
Operational records that exist in the platform today, without exposing learner outcomes.
A platform administrator can provision an organization around an existing eligible facilitator and record attributable operating history.
An authorized facilitator can see membership role and whether a current baseline or comparable reassessment exists.
A participant can keep the future aggregate preference private, record it as aggregate, and revoke it later.
An authorized export includes only memberships already on record and is released only after its audit event is written.
Evidence the organization surface deliberately refuses to expose in this release.
Individual scores, levels, responses, exercise text, and named evidence counts are not exposed to facilitators.
Dimension means and scorer counts remain withheld rather than being inferred from live member records.
Progress, artifact, credential, and contributor totals remain outside the organization outcome response.
The organization outcome response stays closed at every roster size; reaching a headcount alone cannot activate reporting.
Gates that must exist before participant attachment or outcome reporting can expand.
An expiring organization invitation must be accepted by the signed-in participant before a roster claim can attach an account.
Fixed cohort snapshots and reporting windows must prevent longitudinal differencing before any aggregate is calculated.
The minimum applies only after the snapshot and reporting-window protections exist; it never overrides an individual preference.
Signed scope must state what is read, where processing occurs, who can access it, what is retained and for how long, and what may leave the approved environment.
A signed client-source boundary must name the approved processing location, authorized access, retention and deletion period, and egress rules before any repository is opened. Access to source never activates learner outcome reporting.
The HLT healthcare track is authored today. Telecom, financial services, and government are conditional constraint layers that would be composed with named client owners only within a signed engagement; they are not current tracks or credentials.
The graph and published gates stay fixed. Sector constraints are authored or contracted explicitly.
Healthcare demonstrates the authored pattern today. Any other sector layer would be built on the shared framework after scope, subject-matter ownership, review requirements, and credential terms are agreed in writing.
Clinical operations, prior auth, documentation, and member services under PHI discipline. Clinician-in-the-loop gates and staged validation are the curriculum, not an afterthought.
A signed engagement could compose a constraint layer for network operations, field force, or customer operations. No telecom track or credential is authored today.
A signed engagement could compose a constraint layer for reconciliation, research, compliance drafting, or model-risk review. No financial-services track or credential is authored today.
A signed engagement could compose a constraint layer for public-sector policy, transparent evidence, and applicable review requirements. No government track or credential is authored today.
A signed scope could use virtual-first delivery across time zones while keeping the same authored graph and published gates. Schedule, language, venue, staffing, data handling, and any credential terms would be confirmed before delivery.
Working hours and attendance windows would be agreed in the signed delivery schedule.
Core tracks are authored in English. Any translated or multilingual delivery would require signed scope and qualified delivery coverage.
An in-person Operator Lab would require a confirmed venue, qualified staffing, agreed data rules, and signed delivery terms.
A planning scenario, not a result or forecast. Team size, loaded cost, and compressible hours are adjustable inputs; 60% capture and 46 working weeks are visible model assumptions, not measured LockedIn outcomes. Program investment is not included, so this does not calculate ROI. A pilot would test the assumptions; none has run yet.
This is a proposed commercial motion, not a record of completed engagements, revenue, transformation outcomes, or automatic product behavior. Each motion would require separate signed scope and evidence.
Under signed delivery terms, a private cohort could train participants on the client's approved workflows, constraints, and cadence.
A forward-deployed team could work alongside the client to move an approved priority workflow toward production, with controls, documentation, and an operating plan.
An engagement could surface another capability gap in engineering, product, strategy, security, or operations and inform a proposed next training scope.
The HLT track trains clinical, operational, and IT leaders to operate AI where mistakes are regulated: PHI guardrails, validation discipline, and clinician-in-the-loop gates as first-class design constraints.
What changes when your industry has regulators: the constraint landscape, and why it is a design input, not a blocker.
Technical and procedural guardrails for health data: de-identification, access scoping, and audit trails that hold up.
Agents in the clinical back office: intake, documentation, prior auth, and follow-up — modeled with synthetic data and an explicit human gate.
How to validate AI where 'move fast and break things' is illegal: silent runs, shadow mode, and staged evidence.
Capstone: a transformation roadmap for a health organization — workforce, governance, and sequencing under regulation.
In a scoped discovery session, we would map named roles and constraints onto the framework and propose the first program for review. No delivery begins until staffing, schedule, data terms, commercial terms, and scope are signed.
