Production to support, the handoff that decides the next ticket

The acceptance gate
for site documentation.

It reviews a finished smart-home site doc and decides whether support can actually service the client from what is written.

It clears the doc, or sends it back to the tech who owns the gap. It never invents a value, never rubber-stamps to be agreeable, and never lands the rework on you.

View on GitHub Try it in 60 seconds

Local-first folderNo rubber-stampsRoutes back to the tech

site-doc acceptance gateawaiting submission

Site doc half-finished

OvrC attestationblank

Remote access (DDNS / VPN)blank

Wi-Fi SSIDblank

Cameras / NVROther

Control systemCrestron Home

Zone audioKitchen, Library

Marshal

reviewing

Remote-access path blank: support locked out
OvrC attestation not checked
Wi-Fi SSID missing
Camera recorder left as "Other"

auto-loops

If support cannot service it from what is written, it does not get through. That is the whole job.

The problem

The doc is the only thing support has to go on.

Every install ends with a site document, then it gets handed to support. Half of them come back over half-filled, and confirming that lands on one overloaded desk. If that person is fixing every doc, they may as well be filling them out. Marshal is the gate that replaces them.

verdicts. Accepted, returned to the tech, or escalated. It always decides.

gate between the install team and support, so gaps surface before the client does.

rework on your desk. The punch list goes back to whoever made the gap.

Where it sits

Between the bottleneck and the rubber stamp.

Manual QA

One person re-checking every doc

The judgment is real, but it does not scale and it burns out the one person who can do it.

Marshal sits between

Decides, then routes

It applies the same judgment every time, clears what is service-ready, and sends the rest back with a precise punch list.

Generic templates

A checklist with no judgment

A required-fields form catches blanks. It cannot tell whether what is written can actually service the system.

The methodology

It is a folder. That is the point.

No app to install, no model to fine-tune. Marshal is interpretable context: each file does one job, and the only domain-specific layer is one folder you swap. Drop it into any AI assistant and it runs.

marshal/ ├─ brief.md # the client brief (the client is me) ├─ identity.md # who Marshal is, what it owns ├─ rules.md # the decision logic. the engine ├─ examples.md # worked decisions + the edge cases ├─ PATTERN.md # the logic, decoupled. build your own ├─ background.md # why it exists, where it goes next ├─ reference/ # the domain layer (the part you swap) │ ├─ support-critical-fields.md │ ├─ contradiction-checks.md │ ├─ support-advisories.md │ └─ _template/ # fill-in kit for your own handoff ├─ sample-run/ # a full before/after, runnable now │ ├─ sample-site-doc.md # gapped -> RETURN │ └─ sample-site-doc-corrected.md # fixed -> ACCEPTED └─ docs/ # this site

The engine never changes

rules.md holds the order of operations, the three verdicts, and the escalation rules. You keep it as is.

You swap one folder

reference/ is the only domain layer. Copy _template/, fill in the items, the must-have fields, and your front door. PATTERN.md shows the handoffs it fits, from field-service closeouts to loan underwriting to clinical intake.

What you get

One of three calls, every time.

ACCEPTED

Cleared for handoff

Every present system is documented to service, with any support advisories attached so tier-1 is not surprised.

RETURN TO TECH

A precise punch list

Exactly what is missing, addressed to the submitting tech. The rework goes back to whoever owns the gap.

ESCALATE

The call a tech cannot make

The rare judgment that belongs to the production manager, routed up instead of guessed at.

The part nobody else does

It reads the rack photos.

Techs mark up the rack and closet shots. Marshal reads them, pins the exact gear the form left generic (the processor model behind "Crestron," the named switch behind "UniFi"), and catches anything installed but never written down. The form can be vague. The photo is not.

reading rack-closet.jpg4 devices found

Crestron CP4-R in Control
UniFi USW-Pro-24 in Network
Uniview NVR301 in Cameras
WattBox WB-800 not in the form

Try it in 60 seconds

Drop the folder in, paste a doc, ask.

Load the folder

Drop the marshal folder into a Claude project, or paste its files in as context.

Paste the sample

Paste sample-run/sample-site-doc.md and ask: "Run Marshal on this doc."

Watch it decide

You get RETURN with a punch list. Paste the corrected doc and watch it ACCEPT cleanly. The gate runs both directions.

Then run the part nobody else does: hand Marshal sample-run/photo-catch-input.md with the marked-up rack photo attached. It returns a doc that marked Cameras N/A while the photo plainly shows an NVR. The form denied a system; the photo caught it.

Where the line is

What it will never do.

Invent a value to fill a blank it cannot confirm.
Rubber-stamp a doc to be agreeable.
Land the rework on your desk instead of the tech's.
Escalate something a tech could have fixed alone.

This is not a demo built for a contest. It is the working logic for a beta heading to a real industry support partner, scoped and stress-tested cold. The contest just set the deadline.

Get the folder on GitHub