Services

What a forward-deployed team actually does.

LockedIn Labs puts engineers inside the operation, not beside it. The engagement runs in five phases, each one ending in something the client keeps and can operate without us. This is the whole list — what each service is, what it leaves behind, and where it stops.

Every entry names the platform capability that backs it. Where the platform holds the record and engineers do the work, the entry says so. We do not publish client names, outcome figures, delivery durations, or rates: the first two are not ours to publish and the second two are decided per engagement, in the room.

The platform side of this catalogue is the capability register →

01Method phase

Assess

Map the operating reality: the people, the systems, the policies, and the exceptions nobody wrote down. Nothing downstream is allowed to start from an assumption that was never written down and never checked.

S-01

Operating-reality assessment

Lifecycle: Discover

What it is: Structured field work inside the operation: interviews with the people who actually run the process, the documents that are genuinely in force rather than the ones in the policy library, the systems of record, the approval chains, and the exceptions that keep the business moving and appear in no diagram. Everything gathered is attributed to the source it came from, and system, interface, and dependency facts are recorded only from exact current corroborated observations and available source digests.
What it leaves behind: A workspace of immutable source records with content digests, interview records, and attributed observations; plus versioned system, interface, and dependency records retaining exact citations, role-valued responsibility, and provider review. Every gap is recorded as a gap.
Where it stops: We do not summarise an operation we have not been shown. An observation with no source does not become a finding, and an unanswered question is published as an unanswered question rather than an inference. Connector metadata does not discover, connect to, or execute against a system, and provider review is not client confirmation.
Platform support: Built — Discover baseline, governed retrieval, and the evidence-bound system inventory. File ingestion, malware quarantine, AI-assisted extraction, connector discovery, and client confirmation are not implemented; documents are read by engineers and captured as attributed observations by hand.
In the registerC-02 · Discover baseline C-03 · Governed retrieval and system inventory

S-02

Structured capability assessment

Lifecycle: Discover

What it is: The scored instrument that turns field work into comparable findings: a provider-governed assessment playbook with declared dimensions, evidence requirements, organization-role requirements, and gates is reviewed, published, and pinned exactly into the engagement plan. Each dimension is scored against cited evidence, gaps can open obligations owed by a client organization role, and a deterministic cited workcell prepares the next human review without acting for them.
What it leaves behind: A sealed playbook version and exact plan pin; evidence-linked scores on a recorded 0–5 scale with recorded 0–100 dimension weights; a request register that keeps the owing client organization role, requester, resolution actor, and exact fulfilment source; a coverage table naming every gap; and cited work orders whose accepted proposals leave only a non-authorizing handoff to a registered human action.
Where it stops: A plan cannot reach coverage-complete while a required dimension has no accepted score, unless a named human records the variation and their act stays on it. Fulfilling a request does not satisfy coverage, and a score with no evidence link is refused by the system. The workcell calls no model, prompt, tool, connector, or external system; accepting a proposal executes nothing.
Platform support: Built — Assessment Studio, provider-governed assessment playbooks, the engagement-scoped evidence-request register, and deterministic cited workcells. AI-drafted plans, model triage, file ingestion, and client-home request projection are not implemented.
In the registerC-04 · Assessment Studio

S-03

Baseline validation

Lifecycle: Discover

What it is: The act that converts gathered material into something downstream work is allowed to rely on. The onboarding mandate stores sponsor responsibility as the client organization and role. A baseline is drafted, reviewed, and then validated — not by us — through an attributable act by an authenticated client actor currently serving that role, against an evidence digest that pins exactly what they were shown.
What it leaves behind: A validated baseline version carrying the sponsor organization and role, plus a separate validation trail that attributes the act to its authenticated principal, the evidence digest, and the recorded limitations. Superseding it produces a new version; the old one remains.
Where it stops: The delivery side cannot validate its own baseline. The platform refuses a validation act from anyone outside the client organisation holding an accountable role, and that refusal is enforced in the data layer, not in the interface.
Platform support: Built — Discover baseline, client-side decision authority.
In the registerC-02 · Discover baseline C-17 · Named acts and separation of duties

S-04

Opportunity portfolio and proposal

Lifecycle: Discover → Design

What it is: The assessment resolved into a ranked, evidence-linked set of opportunities — the honest version of “the top ten workflows to touch” — and then into a proposal the client can actually decide on. Ranking is derived from the recorded dimension weights and accepted scores by a deterministic rule, so two people running it get the same list.
What it leaves behind: Accepted opportunities traceable to the baseline that justified them, and immutable proposal versions with ranked items, internal review, submission, and the client's recorded decision with the decider's name and note.
Where it stops: Effort, savings, and ROI are never derived. Where a figure is unknown the platform prints it as unknown and states the assumption instead of filling the gap. A dimension that was never scored is held back from the draft rather than treated as a zero. Acceptance of an opportunity is a named human act, always.
Platform support: Built — opportunity portfolio, proposal versions. AI opportunity generation is not implemented.
In the registerC-05 · Opportunity portfolio C-06 · Proposal versions

S-05

Assessment report and executive readout

Lifecycle: Discover → Design

What it is: The submittable report: executive summary, evidence-qualified findings, the current-state picture, the opportunity portfolio, and the decision record — assembled as a projection of the records rather than written as a separate narrative that can drift from them.
What it leaves behind: An issued report version with cited narrative sections, three required disclosure statements, and pins to the exact baseline, assessment plan, and proposal version it was composed from — plus a chrome-free print rendering of that exact immutable version.
Where it stops: A quantitative claim in a narrative section without a citation is refused at assembly. A report cannot be issued if any record it pins has since been superseded; it goes stale, and stale is a first-class state with a recorded reason, not an error. AI section drafting and summarisation are not implemented — the narrative is written by the engineers who did the work.
Platform support: Built — Report Studio, print-ready executive summary.
In the registerC-07 · Report Studio C-19 · Print-ready executive summary

S-06

Transformation strategy and outcome contracts

Lifecycle: Design

What it is: Deciding what “better” would mean, in writing, before anything is built. Each selected opportunity gets a measurement contract naming the metric and its source, the population, the measurement window, the baseline measurement (or an explicit statement that it was not measured), the target and its deadline, the accountable organization role, the decision-authority organization role, leading and lagging indicators, guardrails, cost and human-intervention measures, attribution assumptions, cadence, and accepted limitations.
What it leaves behind: Published outcome definitions bound to the baseline and the opportunity, immutable once published, superseded rather than edited.
Where it stops: The platform will not invent a baseline measurement. “Not measured” is a legitimate, recordable answer and a common one; a fabricated prior figure is not. Publication is reserved to a current member of the recorded decision-authority or accountable organization role.
Platform support: Built — outcome definitions. Maturity assessment, target-state scenario comparison, and architecture decision records are specified but not implemented.
In the registerC-08 · Outcome definitions

S-07

Roadmap sequencing

Lifecycle: Design

What it is: Quick wins, enabling foundations, and long-horizon work sequenced as one plan with dependencies made explicit, in declared streams, against the horizon each item belongs to.
What it leaves behind: An immutable roadmap version with sequenced items, declared modernisation streams, a fully shown accountable role and stage gate for every item, and backward-only dependencies — internally approved, projected to the client, then approved by an authenticated client-side actor under current role authority, then activated.
Where it stops: There are no dates in the roadmap because the system holds no date to be honest about: horizons are categorical (30 days, 60, 90, longer horizon). A roadmap item cannot exist without a published outcome contract covering exactly its opportunity — that gate is structural, enforced in the database, not a review checklist. Forward and circular dependencies are impossible to record.
Platform support: Built — roadmap versions. Cross-proposal dependency graphs and AI roadmap balancing are not implemented.
In the registerC-09 · Roadmap versions

S-08

Workforce and enablement planning

Lifecycle: Design → Improve

What it is: The people side of the reallocation, planned as evidence rather than as an afterthought: which roles and teams the change touches, what is eliminated, simplified, automated, AI-assisted, or newly created, and what enablement each affected team needs before anything runs.
What it leaves behind: Role impact assessments accepted by two distinct named humans, one of them in the client organisation, and enablement tracks that move planned → scheduled → running → completed, with completion carrying a retained evidence digest and an evidence statement.
Where it stops: The platform holds no person record for this. There is no column for an individual anywhere in the workforce planner — roles and teams only — so individual-level judgment is structurally out of scope rather than discouraged by policy. A zero-change assessment is refused; suspending a track requires a recorded reason. Skill transition paths, succession-risk surfacing, and AI curriculum drafting are specified but not implemented.
Platform support: Built — workforce planner.
In the registerC-10 · Workforce planner

02Method phase

Embed

Engineers on site, inside the client's identity and access controls. Read-only first. Nothing rehosted.

S-09

Embedded engineering placement

Lifecycle: all stages

What it is: Engineers working inside the client's environment, under the client's identity provider, access controls, review process, and change management — not a remote team with an exported copy of the operation.
What it leaves behind: Work in the client's own repositories, pipelines, and ticketing, attributable to named engineers, reviewable by the client's own reviewers.
Where it stops: Access starts read-only and widens only by a named grant. We do not rehost a client's systems to make our work easier, and we do not ask for standing production credentials because a workflow would be more convenient with them.
Platform support: The platform records the engagement, its named participants, and their exact roles — engagement and organisation records. It does not provision access to client systems, hold client credentials, or connect to anything: no credential column exists anywhere in the schema.
In the registerC-01 · Engagement and organisation records

S-10

Control and verification design

Lifecycle: all stages

What it is: Designing what checks the work: what restricts access before work starts, what checks work while it is happening, what gates a release, and what watches production afterwards — with each verifier given a defined trigger, a defined scope, the authority to block, and an accountable organization role for the disposition.
What it leaves behind: A written control design the client's own security and risk functions can review, and gates implemented in the client's own pipeline, where they belong.
Where it stops: No agent verifies its own output. Monitoring is the last line of defence, not the control — and it is the one most often mistaken for one. The control design is an engineering deliverable inside the client's estate; the platform does not run verifiers, hold gates, or issue receipts today.
Platform support: None yet as durable capability. The verifier model, the exact-effect authorisation hold, and independent verification exist as a local preview only — process-local and synthetic, with no production effect.
In the registerControl plane status

03Method phase

Build

Working software against the validated baseline, delivered inside the client's own controls and review gates.

S-11

Software delivery inside the client's controls

Lifecycle: Deliver

What it is: Building the thing: services, integrations, data work, interfaces — engineered against the validated baseline rather than beside it, so what gets built is traceable to the finding that motivated it and the outcome contract it was meant to move.
What it leaves behind: Running software in the client's repositories, the configuration that encodes every constraint of their environment, and the eval set that defines what “working” means after we are gone.
Where it stops: Delivery runs in the client's environment under the client's controls. LockedIn Labs FDE does not build, deploy, host, or run this software. It holds the record of why it exists and what it was meant to change.
Platform support: The traceability chain only — baseline → opportunity → outcome contract → roadmap item.
In the registerC-02 · Discover baseline C-05 · Opportunity portfolio C-08 · Outcome definitions C-09 · Roadmap versions

S-12

Workflow definition engineering

Lifecycle: Design → Deliver

What it is: Designing a future-state process as a typed graph rather than a drawing: trigger, automated, agent, tool, human-gate, verification, and outcome steps, each carrying a written boundary statement and an explicit declaration of what it may touch — compiled, reviewed, approved by someone other than its author, and published against a published outcome contract.
What it leaves behind: An immutable published workflow definition with a content digest, every step's boundary in writing, every human gate named to its owning role, and the compiler's verdict recorded.
Where it stops: A published definition acquires no power to act. Tool and system bindings are reference strings; nothing resolves them, nothing dispatches them, and no runtime exists on this path. The compiler refuses a graph with a missing trigger, outcome, or verification step, with unreachable steps, with cycles, with an ungated write-effect tool, or with an unverified outcome path after a write — and it refuses with a named diagnostic, not a warning.
Platform support: Built — workflow definitions. Simulation, deployment plans, registry-backed bindings, AI graph drafting, and any execution engine are not implemented.
In the registerC-12 · Workflow definitions

S-13

Agent definition engineering

Lifecycle: Design → Execute

What it is: Defining a bounded agent in the client's context: its role, its objectives, the model routes it is eligible for, its tool allowlist, its context purposes, what it may touch, what it may delegate, and where it sits on the agentic ladder — with a written justification, because an agent is never the default rung. Every definition carries an evaluation plan, and the evaluation is run before approval is possible.
What it leaves behind: An immutable published agent definition with its evaluation plan, the deterministic evaluation results and their digest, the recorded justification for its ladder rung, and approval by someone other than its author.
Where it stops: A published agent definition acquires no power to act. No session, dispatch, executor, or model provider exists on this path. The evaluation is a pure deterministic function of the definition — it makes no model call and no network call — and it refuses the evaluated act if any check fails, including checks the definition wrote against itself.
Platform support: Built — agent definitions. Bounded execution, model routing, context pack binding, and model-executed evaluations are not implemented.
In the registerC-13 · Agent definitions

S-14

Integration and connector design

Lifecycle: Design → Deliver

What it is: Designing how the client's systems are reached: which system, which mechanism, what it is for, and what the contract between them is — recorded as descriptive entries so the estate the work depends on is written down rather than remembered.
What it leaves behind: An immutable connector register: dotted key, system and display name, kind (MCP, REST, CLI, server-to-server, event, file pipeline), a capability statement, and a reference-only locator.
Where it stops: Registration is never execution authority. Every entry in the platform is pinned by a database check to the metadata-discovery rung of the connector maturity ladder; the four rungs above it — governed read, proposed action, controlled write, operational automation — each require their own increment carrying their own authority model, evidence, and human gates. Raising a connector is a migration, never a flag flip. No credential column exists, every text field rejects secret-bearing content, and no network call exists on this path.
Platform support: Built — connector registry. Schema and mapping validation, dry-run traces, credential vaulting, and any connection to any system are not implemented.
In the registerC-14 · Connector registry

04Method phase

Shadow

The client's team runs the system while the engineers stand behind them.

S-15

Pilot design and chartering

Lifecycle: Execute

What it is: Designing a bounded pilot before anyone runs one: the hypothesis, the affected population, how long it runs for, what success looks like, what stops it, how it rolls back, and which environment it happens in — all required, none optional.
What it leaves behind: An immutable pilot charter carrying all of the above, internally approved, accepted by a named person in the client organisation, and mobilised only when the outcome contract behind it is still published and the affected team's enablement track is actually running.
Where it stops: Execution is not claimed. LockedIn Labs FDE holds the charter; it does not run the pilot, dispatch anything, deploy anything, or collect run evidence. Every charter on every surface prints that sentence. The pilot itself runs in the client's environment under the client's controls, and the work of running it is engineering work, not a platform feature.
Platform support: Built — pilot charters. Pilot work packages, deployments, run evidence, and outcome reviews are specified but not implemented.
In the registerC-11 · Pilot charters

S-16

Shadow operation

Lifecycle: Assure → Operate

What it is: The client's team operates the system with our engineers behind them rather than in front of them — decisions inspectable, actions attributable, and the failure modes met while someone who has seen them before is still in the room.
What it leaves behind: Runbooks written by the people who will use them, the incident and decision record from the shadow period, and a set of operational checks the client's own team owns.
Where it stops: Shadow ends on a date agreed at the start, not when it feels comfortable. If the client's team cannot operate the system without us, the engagement is not finished, whatever the invoice says.
Platform support: None as durable capability. Operations, incidents, queues, and observability are specified but not implemented. Role impacts and enablement tracks are the part that exists.
In the registerC-10 · Workforce planner

05Method phase

Transfer

Code, configuration, evals, runbooks, and the full decision record change hands. The engineers leave. The capability stays.

S-17

Capability transfer

Lifecycle: Operate → Improve

What it is: The handover, treated as the point of the method rather than a closing formality. The client's team takes ownership of the code, the configuration, the eval set that defines working, the runbooks, and the record of why the system behaves as it does.
What it leaves behind: Everything above, in the client's own systems, plus the decision record and the enablement tracks with their completion evidence.
Where it stops: We do not architect for dependency. Critical knowledge does not stay in an engineer's head as a renewal strategy, and integrations are not made sticky on purpose.
Platform support: Partly built. The decision record — baselines, opportunities, proposals, reports, outcome contracts, roadmaps, role impacts, charters, and definitions with every named act — is held as immutable versions. The capability transfer package as a single assembled export is specified but not implemented; today it is assembled by engineers from the records the platform holds.
In the registerThe whole register

S-18

Outcome measurement and review

Lifecycle: Improve

What it is: Recording what happened against the contract that was written before the work started — the metric named in the contract, over the population named in it, in the window named in it. The narrow register opens immutable measurement terms for the owning organization and accountable role, then accepts exact human-recorded readings with the method, evidence source, timestamp, and attributable actor retained on each row.
What it leaves behind: Immutable declared terms and an append-only register of exact readings, each retaining its unit, method, evidence citation, taken time, and the authenticated principal who performed the recording act.
Where it stops: A missing reading remains missing, never zero. The register does not collect automatically, interpolate, backfill, project a trend, compare readings with the target, judge realization, or calculate money. Automated or runtime collection, platform-computed comparison and realization review, and financial realization remain unclaimed.
Platform support: Built — outcome definitions, declared measurement terms, and exact human-recorded readings cited to their method and evidence. Automated or runtime collection, platform comparison and realization review, and financial realization are not implemented.
In the registerC-08 · Outcome definitions

The licensing branch

For other forward-deployed firms

The platform is a separate thing from the firm that runs on it. Two services exist for practices that want to run their own method on it.

S-19

Platform licensing

What it is: LockedIn Labs FDE configured for another practice's engagements: their phases, their gates, their playbooks, their artifact names — running on the platform rather than rebuilt as one.
What it leaves behind: An operating instance holding your engagements, and the register of what the platform does and does not do, in writing, before you sign anything.
Where it stops: There is no self-serve trial, no public sign-up, and no multi-tenant SaaS today. The isolated Git-linked FDE host serves the public front door at fde.lockedinlabs.ai, and the exact code-bearing public web release is production-verified; there is no accepted customer production identity, data, or Storage. Managed service, dedicated instance, private or VPC, hybrid, client-premises, and licensee operation all remain planned individually, and none is purchasable. What exists now for evaluation is a scheduled working session on a dedicated environment, under NDA.
Platform support: Deployment topology status.
In the registerC-23 · Hosting, identity, and deployment topologies

S-20

Assessment-method enablement for a licensee

What it is: Getting another firm's engineers productive on the current method layer: configuring a versioned assessment playbook with their dimensions, evidence requirements, provider and client organization roles, and review gates; walking their leads through the record model; and reviewing the first engagement launch with them.
What it leaves behind: Their assessment method encoded as a sealed, published playbook; an engagement plan pinned to the exact published version; and the same decision-record discipline applied to every review, publication, and launch act.
Where it stops: We do not run your engagements for you, and we do not take your client relationships. The built configuration boundary is the assessment method: custom lifecycle phases, arbitrary artifact types, licensee operation, and customer deployment remain planned. If both firms are on the same opportunity, we say so before the working session, not after.
Platform support: Built locally — provider-authored, database-sealed assessment playbooks with separated review and publication, and exact published-version launch into an engagement. No model, tool, connector, workflow dispatch, or external effect exists on that path.
In the registerC-04 · Assessment Studio

Engagement shapes

Three shapes, described by what each is for.

No durations, no rates, no team sizes — those are decided per engagement.

Shape	What it is for	Ends with
Assessment	An operation nobody has mapped end to end, where the argument is about which problem to solve first.	A validated baseline, a ranked opportunity portfolio, a submitted report, and published outcome contracts.
Build	A decided problem where the work is engineering, not analysis.	Running software in your repositories, the eval set, the runbooks, and the decision record.
Embedded practice	A programme where the capability has to end up inside your team, not inside a vendor.	The above, plus role impact assessments, enablement tracks with completion evidence, and a shadow period that ends on an agreed date.

Refusals

What we do not do.

We do not publish client names, logos, case studies, or outcome figures. If a client wishes to be a reference they arrange it themselves, with us in the room.
We do not staff a seat. If the work is a body in a chair rather than a capability that outlives us, we are the wrong firm.
We do not take standing production credentials for convenience.
We do not run a client's pilot from our platform. The platform holds the charter; the pilot runs in the client's environment, under their controls.
We do not hold compliance certifications we have not earned, and we do not imply a regulatory posture by adjacency. Healthcare and other regulated accelerators are specified as optional profiles and carry no compliance claim.
We do not offer a public demo. Demonstrations are scheduled sessions under NDA, because the platform holds client operating context and the method is the intellectual property.

Bring us the operation, not the brief.

The first conversation is about what the work actually is, who runs it today, and what you would keep if we left. Demonstrations are scheduled sessions under NDA; there is no public trial.

Request a briefing