Trammel
Trammel is a shop-first industrial verification tool for fabricated pipe spools, built around reducing late rework and repeat verification pain.
30-second version
Trammel is a narrow industrial verification tool aimed at catching costly spool problems earlier, before they turn into rework, delay, and repeat verification pain.
Why this has a shot
The founder fit is real, the first wedge is smaller and sharper than it used to be, and the project has already gone through meaningful reduction instead of pitch inflation.
What still has to be proven
The core hardware question is still the shared inter-head measurement method and its repeatability in real shop conditions.
How to read this page: A general reader can stop after the problem, founder, and current stage sections. A technical reader should keep going into the V1 lock, architecture direction, and project record.
Need the plain-English story first? Open Why This Exists.
1. Problem and commercial context
This venture starts from a real industrial cost problem, not from a generic AI opportunity statement.
Trammel exists because when a fabricated spool fails late, the shop often gets hit twice: first in rework, then again in delay, repeat verification, and downstream schedule pain.
That matters everywhere, but it matters even more in Newfoundland. Local fabrication is already under cost pressure. If late spool errors create another loop of correction, signoff delay, or repeat measurement, local work becomes even harder to keep competitive.
- Rework cost
- Schedule slip
- Repeat verification friction
- Lost confidence in first-pass readiness
This venture is built around fabrication reality, not around adding an AI layer to office software. The value is operational: catch critical end-condition problems early enough to avoid a second hit.
Why the rework can get ugly fast: this is not always light cleanup. Some offshore piping can be around 42 mm wall thickness, which means a bad end condition can turn into heavy rework, machining, refacing, or even removing a weld that may have taken the better part of a shift to do properly in the first place. Welding also has its own dimensional-control problems: heat and pull can move a spool out of alignment in ways that are expensive and hard to catch without another survey loop.
If someone does not know spool work or surveying, the simple version is this: shops often do not find a bad spool soon enough. Trammel is meant to help catch that earlier, against the drawing that already exists, so the shop does not keep paying for another round of checking, another survey, and another delay.
Current commercial thesis: Trammel is a competitiveness tool company built around reducing late spool pain in a high-cost environment, not around novelty or AI branding.
Longer-term scale path: the first commercial use is shop confirmation, but the underlying logic is broader than that one moment in the workflow. If the system can confirm spool truth in the shop, the same approach can later support field use on the same kinds of jobs, then grow into broader dimensional control and more polished mechanical reading tools. The mature version does not need to stay limited to pre-survey confirmation forever.
One later advantage if the system matures: a normal survey result is usually a static output taken at one point in time. Trammel has the potential to become more useful during correction itself, because the same confirmation logic can eventually support continuous live feedback while a spool is being manipulated, dry-run, or pulled into fit.
Competitive view: adjacent products already exist in spool drafting, fabrication management, laser metrology, and tube inspection. That is useful because it proves the broader QA/QC and dimensional-control market is real. The gap Trammel is trying to occupy is narrower: a shop-first confirmation tool that starts from the known isometric target and tells the fitter or fabricator what is out before the job turns into another survey and rework loop.
2. Founder and field background
Founder fit matters here because this product only gets stronger when it stays tied to actual fabrication logic, field conditions, and verification work.
Scott Cochrane is a third-generation pipefitter and steamfitter, a medical gas technician, and a certified rigger. He has worked offshore on the White Rose project and has also served as a union shop steward. Trammel is being shaped from that operating background, not from generic software-founder positioning.
- Third-generation pipefitter and steamfitter
- Medical gas technician and certified rigger
- Recent offshore experience on White Rose
- Union shop steward with direct labour-side credibility
- Understands the cost of failed spools in practice, not just in theory
- Self-taught technical builder working across product, infrastructure, and implementation
- Real proximity to training centres, fabrication environments, and shop workflow
Trammel is stronger because it is being shaped by someone who has worked inside the environments the product is meant to serve. The venture keeps moving back toward practical verification because the founder knows what weak tools, vague claims, and awkward workflow fit look like when they reach the floor.
That is why the project repeatedly narrowed away from broad scanner claims, generic AI language, and demo-first thinking.
Plain version: this is not an "AI founder" story, and it is not just "a pipefitter with an app idea." It is a tradesman-operator building a focused verification tool from direct industrial experience.
One old joke behind the idea: on the floor it used to feel like we were still solving modern fit problems with a $100 level while the survey side had the $10,000 tripod. Trammel is meant to be the actual tech upgrade in between, not another round of waiting for old workflow to catch up.
3. Operating base already in place
Trammel is not just an idea in a notebook. There is already infrastructure, tooling, documentation, and technical momentum behind it.
This is not a case where the founder is starting with just an idea and asking for resources before any real work starts. There is already a working stack, internal infrastructure, documentation, and ongoing R&D discipline behind the venture.
- united-ai.ca as the builder umbrella behind the current work
- Beacon as a self-hosted edge and deploy platform
- Cortex as a self-hosted memory and embedding layer
- UAPI as a personal API router across multiple AI providers
- Working self-hosted infrastructure already in place instead of starting from zero
- Apple Developer licence and broader build infrastructure already in hand
- Mars 4 Ultra printer already owned for prototype work
- Field access, trade context, and local trust are founder-side advantages, not umbrella-platform advantages
- UA 740 training centre and trade relationships create a path to sample stock and concept testing
- Founder is technical and hands-on enough to build early prototypes in some form
- Hardware engineering help is still needed for the strongest sensing and product path
The venture is starting with working infrastructure and research discipline already in place. The founder separately brings the field access, operator context, and local industrial relationships that make the first wedge more believable. That does not solve the hardware challenge, but it does reduce the gap between concept work and disciplined verification.
4. Current V1 lock
The project got better every time V1 was made smaller, sharper, and more honest.
One of the most important things learned during this project is that the venture gets better every time the first version is cut down to what actually matters. The current V1 is intentionally narrow.
- End-to-end
- Tip / stand-out when called for
- End-face condition against the known target
- Full spool reconstruction
- Survey replacement
- Broad field verification
The first deliverable is supposed to confirm critical end-condition truth before later verification pain lands. That is more believable than trying to solve every measurement problem in one shot.
5. Current architecture direction
This is the current best theory direction, not a final hardware claim.
The strongest current direction is no longer scanner-first, no longer bench-first, and no longer generic measurement-platform thinking. The current working architecture is:
Two smart heads. One shared inter-head measurement path. Deterministic compare against a known target.
That means the system logic is smaller than earlier branches. Each head establishes usable local end truth. The shared inter-head path then tells software how those two local frames relate inside one compare frame. Trammel compares measured reality to the known target and reports what is out.
The important distinction is that Trammel is not trying to rediscover the whole spool from zero. The intended job geometry is already known. The public claim is narrow: target-first confirmation, not full rediscovery.
- Seat and stabilize on one end
- Recover local end truth
- Hand off one side of the compare
- Relate Head B back to Head A
- Carry the compare across the span
- This remains the hard technical problem
- Seat and stabilize on the far end
- Recover local end truth
- Close the comparison against target
- Portable tool logic
- Centerline-first confirmation instead of full regeneration
- Modern hardware path still open
- Local deterministic compare
What exact sensing method gives the two heads a trustworthy shared frame or relative transform? That remains the central technical bottleneck.
Public-safe wording: two end references, one shared compare path, and a deterministic check against the intended target. The deeper geometry logic stays in the private appendix.
Technical appendix: the deeper method and concept-build reasoning are kept in a private appendix for guided review only. Open private appendix. This link only works on the UAI mesh.
6. What is proven vs unproven
The page should separate what is already strong from what is still unresolved. That is part of the venture quality, not a weakness.
- The problem framing
- The first wedge
- The local Newfoundland competitiveness logic
- The need to confirm rather than regenerate
- The need to keep V1 narrow
- Final head geometry
- Final shared inter-head measurement method
- Repeatability in shop conditions
- Commercial proof with real buyers
- Production-ready hardware stack
The honest founder position is that Trammel is strong enough to discuss as a verification-stage industrial venture, but not strong enough to overclaim solved hardware.
7. Rejected or reduced branches
The dead ends matter because they show what was tested, what was cut away, and why the current version is smaller and better.
This project has already paid for several wrong directions. Keeping the dead ends visible matters.
- Scanner-first framing
- Survey-replacement language
- Bench-first product identity
- Promo-video-first storytelling
- Generic AI SaaS positioning
- Too broad
- Not aligned with the actual first buyer pain
- Made the product sound overclaimed or overbuilt
- Added too much hardware and workflow complexity too early
- Pulled attention away from what actually needs to be proven
Why that still matters competitively: existing products tend to sit either upstream in spool software and QA tracking, or downstream in broader metrology and survey-style measurement. Trammel gets more interesting if it can stay between those worlds: tighter than general survey, more intelligent than a passive drawing package, and better wrapped for the actual shop confirmation workflow.
8. Project record
This page is the readable front layer, not the full archive.
Current naming as of March 13, 2026: Trammel is the active working name used across the review package.
There is a deeper internal research and working archive behind the current Trammel direction, including earlier branches, technical notes, prompt rounds, prototype work, and the R&D diary.
This work did not start from nothing. Earlier verification prototypes and reduction work already existed before the current Trammel framing was locked, which is why the project reads as a build record rather than a naming exercise.
For public review, this page stays focused on the current state, the strongest lessons, and the active direction rather than exposing the full working file tree.
9. Current stage
The project is now far enough along to describe clearly, but it is still early enough that the core hardware proof work remains in front of it.
Trammel currently sits in a verification-stage position: the problem is real, the first wedge is narrow enough to matter, the product direction is much clearer than it was earlier, and the remaining unknowns are specific rather than vague.
- The problem is real
- The first wedge is intentionally narrow
- The venture has already gone through real reduction and iteration
- The next proof path is identifiable
The strongest remaining unknown is the exact shared inter-head measurement method and the real repeatability of that method in shop conditions. The page exists to show the current state without pretending that work is already complete.
AI lesson from the build: AI has been useful here as a coding partner, a fast worker, a knowledge aid, a validator, and a sanity-check layer. It has not been a true problem-solver. The actual problem still has to be fixed by someone with perspective, judgment, and responsibility for what is real.
Where AI likely fits later: not as the core product claim, and not as a substitute for getting the geometry right. The near-term fit is document retrieval, workflow help for new users, troubleshooting support, and QA/QC checks against project records and PDFs. The more interesting AI role comes later, after bolt-hole work and enough real spool data exist: helping suggest the best correction path during a dry run, highlighting where a spool is fighting the fit, and showing how far and in what direction it likely needs to move.
Future product path: Trammel should start as a narrow confirmation tool, but it does not have to stay there forever. The same core approach can move from shop confirmation into field use on the same kinds of mechanical jobs, then into broader dimensional control and more capable reading tools once the base workflow is proven. That is the cleaner long-term scale story, not pretending the first version already replaces survey.
10. Piper
Piper is the planned project agent for the record, not a novelty chatbot bolted onto the site.
Piper should work the same disciplined way the earlier internal agents did: narrow scope, grounded retrieval, and direct answers. A lightweight model in the GLM 4.5 Air class is enough if the context is clean and the retrieval is tight.
The agent should stay anchored to TLDR material and the project record. If someone asks a question, Piper should answer from those materials and show exactly where to look next. No filler, no freestyle storytelling, and no pretending the record says more than it does.
That makes Piper the early AI layer that actually fits: retrieval, workflow guidance, troubleshooting, and record-aware support tied back to the source trail.
Intent: Piper becomes a retrieval layer over the future project database and TLDR corpus, with answers tied back to the source trail.