Robot integration · acceptance traceability
Relay is a document-based system that keeps one traceable record of requirements, changes, tests, evidence, configuration, and handover for a custom robot-cell project — so an integrator can prove what was promised, what changed, how each promise was verified, and exactly which hardware and software baseline the customer accepted.
REQ-01FAT-04 passed · run log 18 Aug · PLC v1.8.2
REQ-05SAT-06 planned only — cannot prove delivery
REQ-06EV-023 photo exists · responsible approval absent
CO-002REQ-03 → FAT-07 → EV-018 → robot job R17-42
The signed SOW says the cell will sustain ten cases per minute. A change order swapped the pallet pattern halfway through the build, which quietly invalidated the FAT result that proved it. The SAT retest for the restart sequence is on the plan but nobody can find a record that it ran. The guard panel has a photo but no engineer signature. The PO says final payment follows closure of all punch items; the SOW allows conditional acceptance with Category C items open.
None of that is unusual, and none of it is anyone’s fault. It is what happens when scope, changes, test records, and the as-built configuration are tracked in separate systems by separate people. The cost lands at closeout, when someone has to rebuild the whole story by hand to justify a final invoice — and the customer’s approver is asking the same questions.
Relay’s whole purpose is holding one chain intact from the signature to the accepted cell. Each layer links back to its source and forward to what it affects, so a change at any point shows its consequences everywhere else.
Every obligation in the signed scope, pulled out as a separate record with its source document, page, and exact excerpt attached. Classified as functional, performance, interface, documentation, training, safety-related, commercial, customer dependency, assumption, or exclusion.
Every change request and approved change order, with requester, reason, before/after scope, price, schedule, and the specific requirements, tests, evidence, and configuration items it touches. Requested work is never treated as approved work.
The verification method for each requirement, allocated to factory acceptance test, site acceptance test, handover, or the customer’s own responsibility — so it is always clear where a promise gets proven.
The actual proof each test produced: run logs, dimensional checks, witnessed results, photos, hash manifests — each with its observation date, provenance, and the configuration it was captured against.
The exact robot controller, PLC, HMI, firmware, program revision, parameter set, drawing, and backup revisions that make up the delivered cell — and which of those the customer actually accepted.
The closing package: a single source-linked index tying all of the above together, plus the responsible approvals and decision history that make it defensible months later.
Relay reads authorized project documents, proposes obligations and criteria with exact source citations, detects conflicts between documents, and tracks each obligation through tests, evidence, changes, configuration, and approvals to a commercial milestone. Relay proposes. A responsible engineer decides.
Every document gets a stable ID, revision, and authority level — signed contract, approved change, incorporated reference, draft, or reference-only. A draft can be analyzed but can never alter the accepted baseline, and a signed source is never silently replaced: a revision creates an explicit supersession link.
Relay proposes atomic obligations from each source and flags nine specific defects: vague terms, weak modal verbs, missing measures, missing timing, customer dependencies, exclusions, composite obligations, commercial triggers, and undefined references. Each finding carries the matched text, an explanation, and a corrective action.
Each approved obligation gets a measurable criterion and a verification method, allocated to FAT, SAT, handover, customer responsibility, or explicit exclusion. Composite obligations get split so each deliverable is independently verifiable.
Relay compares registered sources by claim key and reports four outcomes: BLOCKED when two authorized sources disagree, REVIEW when a draft or unincorporated reference would alter the baseline, ALIGNED when values match, and SINGLE SOURCE as a coverage observation. Relay never picks the controlling document itself.
When sources disagree, an authorized reviewer records the controlling claim, the authority basis, and a written rationale, then maps the before/after impact on every affected test, evidence item, configuration item, and payment milestone. The result is a visual change-impact graph and an exportable precedence register.
Milestones and closures report READY or BLOCKED with named reasons, never a vague percentage. Planned work never satisfies a gate. Every mapped item needs a disposition, a named responsible person, a project-record reference, and a fresh review attestation — and any edit clears the result.
Obligation review, acceptance-basis matrix, conflict report, change-impact register, milestone-readiness report, configuration index, decision history, and handover index — as stable-ID CSV for machines and print/PDF for people. Source locations and status semantics survive the export.
Load the signed SOW, PO terms, technical exhibits, exclusions, assumptions, approved amendments, and payment milestones. Set which document controls when two disagree.
Relay proposes atomic obligations with source excerpts and quality findings. A responsible reviewer accepts, edits, rejects, or marks each one not applicable — and the original proposal is kept alongside the human decision.
Attach a measurable criterion and verification method to each approved obligation, and allocate it to FAT, SAT, handover, or the customer.
Connect executed tests, their evidence, punch items, approved changes, and the delivered hardware/software baseline back to the obligations they prove.
Where sources or revisions disagree, a reviewer records the controlling source, the rationale, and the downstream impact. Nothing enters the baseline silently.
Technical and commercial readiness are calculated separately. Relay names what blocks each milestone, and exports the full source-linked handover package for review.
Relay does not issue engineering, safety, contractual, payment, or acceptance approval. Every AI-assisted output stays a proposal until a responsible engineer accepts, edits, or rejects it — and the original proposal is preserved next to the human decision.
Most closeout disputes come from treating different things as if they were the same thing. Relay keeps them separate on purpose.
Relay refuses to let a scheduled procedure stand in for a completed one. Each obligation moves through four distinct states, and only the last one closes it.
“The cell works” is not a deliverable. Relay records the exact delivered revisions — controller and program, PLC, HMI, safety-related hardware, parameter sets, drawings, and backup hash manifests — each with its proof and verification state.
A signed baseline is immutable. A later change creates a new baseline rather than overwriting the accepted one.
Milestones do not report a percentage that hides what is missing. Each one is tied to the criteria, evidence, and approvals it requires, and Relay names the specific blocker.
Unmeasurable “nominal rate” criterion, and a customer material dependency with no required date.
Handover is where a robot-cell project either closes cleanly or turns into weeks of retroactive paperwork. In Relay it is not a single document — it is an index of six connected records, each independently gated, each traceable back to a source. It is the artifact that answers “show me the proof” without a scramble.
Every obligation with its source location, acceptance criterion, verification method, linked test, evidence, and current status — including the blockers that are still open. Unresolved gaps are retained, not hidden.
Every test by phase, with its linked requirement, result, evidence ID, and provenance — including results marked superseded by a later approved change, which stay visible but cannot satisfy the current baseline.
Each change order with its state, owner, and full impact path — for example, a pattern change tracing through the requirement, the replacement FAT test, its evidence, and the robot job revision — plus every punch item and its disposition.
The exact delivered baseline: robot controller and program revision, PLC version, HMI version, safety-related hardware revision, parameter sets, drawings, and backup hash manifests — each with its proof and verification state.
Who approved what, when, and on what authority basis — engineering approvals, precedence decisions, and customer acceptance, each tied to the record it authorizes.
The append-only trail of proposals, human accept/edit/reject decisions, baseline changes, and exports — so the package can still be defended months after the cell is running.
Companies that design, build, and deliver automated work cells to manufacturers under fixed-price or milestone-based contracts — where a single project carries a signed scope, approved changes, FAT and SAT phases, a configuration baseline, and staged payments.
You carry the margin on fixed-price work. Relay names which obligations, unpriced changes, and missing approvals sit between finished work and a released milestone payment.
You hold the project story together from kickoff to handover. Relay keeps scope, changes, tests, evidence, configuration, and approvals in one record instead of a spreadsheet rebuilt at closeout.
You approve the technical work. Relay hands you the source excerpt, the exact criterion, the evidence provenance, and the configuration context — so your approval is grounded, not guessed.
Neither is a self-serve subscription. Both are hands-on engagements scoped and capped before we start, run under a mutual NDA and a redaction addendum.
We take one finished project and your approved, redacted closeout documents, and rebuild the record the way it should have existed.
We keep the record as the project runs, so closeout is an export rather than an archaeology exercise.
We are a founder-led engineering team focused on one problem: on custom robot-cell projects, the signed scope, the tested evidence, and the accepted configuration live in separate systems — and that gap is what delays final payment.
Relay’s engine is deterministic by design. Every obligation, conflict, and readiness gate is computed by explainable, testable rules rather than a black box, and validated against a growing automated test suite. We work directly with robot integrators to refine the record model against real projects and real closeout history.
Get in touch
We are talking with robot-integrator owners, delivery leaders, project and controls engineers, and commissioning practitioners. If closeout is where your projects lose time or money, we want the real version of that story.
We accept authorized, redacted PDF, DOCX, XLSX, CSV, and image files: scope and SOW extracts, acceptance criteria, FAT/SAT forms, change logs, punch lists, configuration manifests, and handover indexes.
We reject credentials and keys, personal data, customer identities, unnecessary pricing, source code, robot or PLC programs, safety logic, live control traffic, network details, export-controlled material, controlled drawings, and unapproved plant data. Prohibited material is refused before analysis rather than copied into tickets or chat.
Working copies carry a deletion deadline set at intake, with a default of 30 days after an engagement completes unless the contract says otherwise. No model training or secondary use without separate written consent. Relay organizes workflow evidence; it does not certify a system, approve safety, replace a responsible engineer, or control a robot.