Map the project.
Find files, symbols, dependencies and tests at a specific version of your code.
PECS · by One Lab
Your project has a history. Your AI should know it.
PECS brings together your code, past decisions and test evidence, so AI starts a change with the context that matters.
Project memory. Better-informed changes. Checkable results.
Preparation Core tested internally. Hosted access and customer pilots are being prepared.
Conceptual project map · synthetic
login.tsselected task
session.tsdependency
recovery.tsrelated flow
auth.test.tsnamed check
billing.tsoutside scope
The missing context
A code file is only part of the story.
Before changing software, you need to know what depends on it, why earlier decisions were made, and what already failed. PECS keeps that context connected to the code—and points you back to the evidence.
- What else will this affect?
- Find connected code and relevant tests.
- Why was it built this way?
- Find documented decisions and previous attempts.
- How will we check the change?
- Identify the checks and constraints that matter.
Synthetic walkthrough · not customer evidence
“Before changing login, show me what matters.”
Illustrative example. Not a customer project or a measured production result.
Task brief · auth-refreshsnapshot · 6f4c2d1
Code to inspect
src/auth/login.ts · src/auth/session.ts · src/auth/recovery.tsHistory to read
ADR-014 session rotation · incident note 2025-11-03Tests to run
sign-in · expired session · logout · recovery linkBoundaries
No permission changes. No production deployment.Unknowns
The ownership of one legacy recovery path is not recorded.What PECS does
Context before code. Evidence after the change.
Keep the history.
Bring documented decisions, previous attempts and failures together with their source references.
Prepare the work.
Build a focused task brief instead of handing an assistant an unfiltered pile of files.
Check the result.
Examine a proposed patch and the named checks that ran in an isolated workspace.
How it works
Understand. Prepare. Check. Remember.
A passing test is evidence—not a guarantee that software has no bugs.
- 01Read the chosen project.
Use approved repository access and a clearly identified code version.
- 02Bring the relevant context together.
Find connected code, tests and eligible project history.
- 03Prepare a focused brief.
Show the coding assistant what matters, what it must not change and what remains uncertain.
- 04Review a checkable result.
For an enabled coding pilot, receive a patch artifact and the results of the checks that actually ran.
Your existing workflow
Keep your coding assistant. Give it project memory.
PECS is not a replacement for your coding model. Its role is to supply project-specific context and make the evidence behind a proposed change easier to inspect.
01The coding assistant
Drafts and edits code.
02PECS
Supplies source-linked context, constraints and verification records.
03You
Decide what gets accepted and deployed.
Technical connection status
Authenticated read-only tools are implemented. No named client is presented as available until that exact client surface passes hosted acceptance.
One Lab relationship · staged connections
One Lab's engineering system—not another disconnected tool.
PECS holds the engineering context. Other One Lab systems may receive only the information and authority their separate contracts permit.
AION
May propose or review a scoped task. It cannot execute it.
AOK
May reference an approved budget reservation. It grants no permission to deploy.
PECS
Owns commit-bound engineering context, task briefs and verification records.
Brain
May receive an approved outcome summary—not unrestricted customer code.
Assure
May record minimized task and verification evidence after authenticated delivery and readback.
Dashed edges represent planned or acceptance-pending connections, not live traffic. PECS remains usable without every module.
Control and uncertainty
Useful answers show their limits.
A specific code version.
Know which repository snapshot an answer describes.
Sources you can inspect.
Follow the file, decision or test behind a result.
Uncertainty that stays visible.
A possible file successor is not presented as a certain one.
No automatic upstream changes.
The current controlled scope does not push, merge or deploy into a connected source repository.
Customer projects must stay separate. Sharing information with another One Lab service requires an explicit, scoped connection.
Who it is for
Built around a project—not just a chat.
Solo builders
Carry project context between coding sessions.
Growing product teams
Understand dependencies and past decisions before making changes.
Engineering teams exploring AI
Inspect proposed changes and the checks behind them.
Current examples and internal evidence cover existing TypeScript and Python repositories. Other languages and blank-project scaffolding are not implied.
Release facts
Start with one project.
We are preparing guided PECS pilots around a defined repository, a useful workflow and clear usage limits. Scope, price and usage allowance must be agreed before activation.
Discuss a PECS pilotCode context, history and task briefsImplemented and tested internally
Controlled patch verificationTested with controlled fixtures
Hosted workspace and client connectionsDeployment and connection acceptance pending
Brain, AION, AOK and Assure integrationsProspective contract; not live
External customer onboardingNot open
Measured improvement in AI coding outcomesNot established
Technical validation
Historical M3-A and M3-B evaluations remain FAIL. Official P1 remains FAIL pending a separately authorized independent validation. Current development regressions do not replace those results, and P2 is not authorized.
FAQ
Clear answers before access.
Is PECS another AI chatbot?
No. It is a project-context and engineering-evidence system designed to support a coding workflow.
Can it build a complete product from one sentence?
That is not the current promise. PECS first makes an existing software project easier to understand and work on. Controlled coding capabilities are being tested separately.
Does it change my repository automatically?
No in the current scope. Proposed work stays in an isolated workspace or patch artifact until accepted through the required process.
What does successful verification mean?
The listed checks passed in the recorded environment. It does not mean every possible defect has been ruled out.
How will pricing work?
Early pilots use an agreed project scope and usage allowance. Public plans remain unpublished until costs and the paid workflow are validated.
A better starting point
Give the next coding session a better starting point.
Bring one repository and one workflow you want to improve.