Wireframes for the four states a customer moves through: open the package, review the board, resolve a finding, and hand the result back to the order. The customer fixes the PCB in their own EDA tool; the spoke never edits geometry.
1
Package overview
Order context, files, detection, and processing status
This screen is the first trust boundary. The order supplies a four-layer package, so all four copper layers are listed and mapped explicitly. Anything the pack does not prove, such as drill plating or a missing paste layer, is shown as a question instead of silently assumed. The manufacturing profile is assigned to the order and the ruleset belongs to the spoke, so the customer sees both versions but cannot change them here. Uploading a revised package adds a revision to the order; it does not replace the current revision or its results. The board on this screen is illustrative until normalization finishes; the viewer renders parsed geometry after the run.
Order PR-10424-layer control boardPackage received 12 Nov, 09:41Revision 3 · Processing
Package preview Normalizing
Illustrative preview · not parsed geometry
Normalizing geometry6 of 8 files · geometry
▦
PCB fabrication4-layer · 1.6 mm · ENIGDetected
▤
Solder-paste stencilTop side · aperture pendingPending paste layer
Interpretation notes
2 warnings
1Plating type unknown. PTH and NPTH are not distinguished. Confirm drill classification before manufacturing.
2No paste layer found. The stencil item stays pending until a paste file is provided or a fallback aperture is approved.
2
Validation workspace
Board viewer, layer control, and the findings wall
The board and the findings stay in one view, because the customer needs to compare a measurement with the geometry that produced it. Selecting a finding is a local action: it highlights and zooms the board without re-running validation. Findings are grouped by technical severity, while checkout impact is shown separately because Trace owns that policy. The profile belongs to the order and the ruleset belongs to the spoke, so both are read-only here.
One issue, its geometry, and what to change in the EDA tool
This is a focused state of the workspace, not a separate editor, and the customer still fixes the board in their EDA tool. The finding states the constraint, the measured geometry, and a suggested remediation framed as guidance. Acknowledgement is tracked separately from resolution: a finding only closes when a later validation run confirms it, never because someone checked a box. Trace owns the original files and revision manifest. The spoke stores the revision reference, content hash, and derived results for each run.
Findings posted back to Trace, order items posted, return to the order
The spoke reports and the hub decides. A run can complete while findings that block checkout remain, so checkout eligibility stays a hub policy rather than something the validator grants. The spoke posts findings and the priceable items it can actually derive from the package, keeps the derived data needed to re-render the board, and leaves cost roll-up, checkout, and production tracking to Trace.
Awaiting paste file or approved fallbackNot priced yet
1
Pending
Total posted
$1,840.00
Handoff to the order
✓
Original package kept in TraceRevision 3 · content hash recorded on the run
✓
12 findings added to the order3 errors · 9 warnings · linked to run 8f2
✓
1 order item added to the orderPCB fabrication posted. Stencil is pending a paste layer.
✓
Validation history availableRun 8f2 · finished 12 Nov, 09:43
The run is complete, but Trace keeps checkout blocked while 3 findings remain unresolved. You can upload a revised package from the order at any time.
Run details
Revision
Revision 3 · sha256:9c1f…4a7e
Profile
Standard 4-layer · Profile v3
Ruleset
Alpha DFM v2.4
Parser
Gerber 0.8.1 · Excellon 0.5.0
What happens next
Fix the three findings that block checkout in your EDA tool, upload the revised package, and run validation again. The stencil item stays pending until a paste layer is provided or a fallback aperture is approved. Trace applies its checkout policy to the new run.
Note: these are wireframes, not a finished interface. Pricing and finding counts are illustrative. The layout is deliberately dense because the customer is comparing measurements, layers, and order items at the same time.