VISUAL REPOSITORY / 01

The visual system, in one place.

Live components, not screenshots. Extend the source visual and every page stays in sync.

HOW LAB0 WORKS

Core explanatory visuals

08 components
ASSEMBLY NOTE

Lab0 doesn’t sit in the middle. It changes the shape of the part.

BC → ASP · PINT AE
SCHEMA MISMATCHLAB0 AI FDEShapes the partDiscover + mapBuild AL extensionTest + correctCUSTOMER ERPBusiness CentralPosted documentsTax + posting setupInbound draftsACCREDITED NETWORKASP + PINT AESubmit + receiveValidate + deliverReport status

Two systems. Two shapes.

Business Central posts documents in its own structure. The accredited network expects PINT AE, down to the last mandatory field.

No middleware. Lab0 is the implementation layer, not a transport layer — the accredited ASP still owns submission, and your data never transits a Lab0 system.

01

Implementation compressed

Source ↗
How a consulting team does it todayby hand, system by system
01Discovery

Weeks of interviews and document reading to learn how Acme actually works.

02Configuration

Hand-setting fields, forms, and rules in each system, one screen at a time.

03Testing

Pushing requests through by hand, finding what breaks, fixing, repeating.

04Go-live

Cutting over, watching for failures, writing down how it was wired.

Typical implementation
~6 months
~9 people involved
With Lab0
Weeks
~3 people involved
Without Lab0
~26 weeks
With Lab0
~4 weeks
DiscoverySystem setupIntegrationTestingGo-live

Consulting phases, team size, and elapsed time on one shared scale.

02

Scattered context becomes a record

Source ↗
Scattered across people, calls, and docs
Kickoff call
“purchases over $2.5k need manager sign-off”
Requirements doc
“IT assets are tracked in ServiceNow”
Integration spec
“send the PO number back to Coupa”
Stakeholder
“finance checks the cost center in SAP”
One structured record
IT purchase = hardware request
Approver = IT manager, in ServiceNow
Finance check = cost center, in SAP
Return field = Coupa reference number

Lab0 turns kickoff notes, docs, and stakeholder answers into concrete implementation records.

03

The fields that matter

Source ↗
14
fields actually matter for this workflow
~4,000 fields
in ServiceNow
Owned by four teams:ITSecurityFinanceProcurement

The fields that matter are spread across teams. Lab0 finds them by inspecting the systems.

04

Field mapping

Source ↗
Field mapping
MatchesNeeds translating
CoupaServiceNow
requester email
requested for
Same value, different name
approval status
ticket status
Values don’t line up
cost center
cost center
Matched
category
category
Matched
+New field added in ServiceNow to hold Coupa’s reference number

A direct view of clean matches, renamed fields, and values that need translation.

05

Conditional translation rules

Source ↗
Customization · approval statuswritten by Lab0
When Coupa saysLab0’s rule writes to ServiceNow
approved
amount ≤ $2,500
Closed Complete
approved
amount > $2,500
Finance review
Closed Complete
pending approval
Awaiting Approval
rejected
Closed Incomplete
+ copy rejection reason into work notes
The same Coupa status lands in a different ServiceNow state depending on the request. Lab0 writes these rules once, and every request then routes itself without anyone re-checking it by hand.

The same source status branches into different target states based on context.

06

End-to-end verification

Source ↗
Test request, end to endPassed
Request raised in Coupa
IT review in ServiceNow
Finance check in SAP
Status back in Coupa

Lab0 works like an implementation engineer: inspect, map, configure, verify.

07

Implementation memory compounds

Source ↗
1st implementation
2nd implementation
3rd implementation
ReusedNew work
total effort →

The first implementation creates the pattern. Every change after it starts ahead.

CONCEPT LAB

Visuals for implementation intelligence.

Research-led prototypes. Each one is static-first, componentized, and ready to extend with motion, real project data, or page-specific variants.

C-01

Implementation compiler

prototype
kickoff call
requirements.docx
live schema
stakeholder reply
Lab0implementation compiler
01decisions
02field map
03rules
04tests
05release

Unstructured project inputs resolve into an executable implementation system.

C-02

Decision lineage

prototype
RequirementPurchases over threshold need finance reviewLIN-001
DecisionRoute by amountLIN-002
Mappingapproval_status → ticket_stateLIN-003
TestUAT-042 passedLIN-004
ReleaseR1.1LIN-005

One requirement stays connected to every decision, mapping, test, and release artifact.

C-03

Failure becomes a skill

prototype
Run 014
SAP tax code rejected
diagnose: missing country rule
fix: map jurisdiction first
skill stored
tax-code-normalizer
Next matching run starts with the fix already attached → passed

A fix stops being project history and becomes reusable implementation memory.

C-04

Change blast radius

prototype
requirements
3 fields
2 integrations
CR-019
new partner type
6 regression tests
release 1.1
commercial scope

A small request reveals every affected artifact before the implementation changes.

C-05

Specialist swarm, one release

prototype
Lead AI FDEimplementation plan
Discoverprocess map
Inspectsystem model
Mapfield contract
Buildconfiguration
Verifytest evidence
One release record

Parallel agents each return a named implementation artifact, not a generic answer.

C-06

Skill library

prototype
SK-01AI interview
SK-02process map
SK-03schema inspect
SK-04field matcher
SK-05rule translator
SK-06connector build
SK-07regression suite
SK-08cutover checks
AI interviewschema inspectfield matcherconnector buildregression suite

The AI FDE assembles the implementation from reusable, inspectable capabilities.

C-07

Known vs unknown terrain

prototype
unknown system surfacetested path through it →

Each implementation expands the tested region inside a much larger enterprise system.

C-08

Parallel time collapse

prototype
Consulting sequence
discover
inspect
map
build
test
Lab0 execution
discover
inspect
map
build
test

Speed comes from overlapping work and reuse, not simply doing each phase faster.

FURTHER OUT

Stranger ways to see an implementation.

These are deliberately less literal. The motion carries sequence and causality, while the static frame still explains itself.

X-01

Implementation MRI

requirement
72%
decision
44%
field mapping
86%
permission
38%
integration
65%
test coverage
92%
implementation cross-sectionweakest layer: permission model

Scan the implementation as a layered system and expose the weakest unresolved layer.

X-02

Handoff entropy

manual handoffscontext loss compounds
buyerpartnerarchitectdevelopertesteradmin
connected implementation recordcontext preserved

Show how context degrades across a consulting chain and stays intact inside one connected record.

X-03

Acceptance-test loom

threshold
owner
status
return field
traceability weave
UAT-041
UAT-042
UAT-043
UAT-044

Requirements are woven directly into executable tests instead of copied into another document.

X-04

Change fossil record

R1core procurement flow
R1.1+ finance threshold
R1.2+ SAP cost center
R1.3+ rejection reason
R2+ second ERP
current system knowledge

Every release preserves the decisions beneath it, so the current system can be reconstructed instead of rediscovered.

BLOWN OUT

Accuracy is optional. Scale is not.

These are composition tests, not product documentation. Some explain. Some just occupy the room.

4,000 → 14XL-01
14the fields that actually matter
Weeks monumentXL-02
elapsed time
SIX MONTHSWEEKS
The same implementation.
A different shape of time.
The black boxXL-03
calls
docs
schema
people
errors
lab0the implementation
map
build
test
release
One line through chaosXL-04
One line survives.
requirements changed
systems disagreed
the workflow still ran
Field map at building scaleXL-05
COUPA
SERVICENOW
requester_email
requested_for
approval_status
ticket_state
cost_center
cost_center
po_reference
u_coupa_reference
company_code
u_sap_company_code
rejection_reason
work_notes
Almost nothingXL-06

The implementation
is finally boring.

status: running
SITE-WIDE

Signature systems

08

Lab0 matrix cube

Lab0 matrix cube
09

Architecture flows

Structured system diagrams place Lab0 between enterprise platforms without turning the page into product UI theatre.

ERP
Lab0
Target
Full reference below ↓
Where Lab0 sits

Between the customer's ERP and your ASP platform.

Lab0 is not the Accredited Service Provider. It is the implementation layer that gets each customer system connected to the accredited network.

INVOICE EXCHANGECUSTOMER CONNECTION: RUNNING
01
Customer ERPinvoice + credit note
02
Lab0 AI FDEinspect · map · transform · test
03
Accredited SPvalidate + exchange
04
Recipient ASPdeliver eInvoice
01schema
02values
03rules
CORNER 5Tax data reporting
01

Accredited Service Providers

Add customer volume without making every ERP connection a new consulting team.

02

Systems integrators

Deliver mixed-ERP e-invoicing programmes with a repeatable implementation layer.

03

ERP and finance transformation teams

Move from ASP selection to a tested customer connection across real instances.