Bayou Connections

A working prototype, built with my brother Jim for his custom-cabinet shop. A homeowner designs a room in 3D: finish, doors, hardware, counters, walls and tile, even the light at a chosen time of day. They can ask for changes in plain words, like “swap the range and the sink”.

Every change is checked against how Jim builds. When something works but deserves a second look, the studio says so plainly, for example when one leg of the work triangle falls outside 4 to 9 feet.

A planning range moves as the design changes. It is labelled planning guidance, not a quote.

When the homeowner sends the design, Jim gets a brief that keeps its sources apart: what the customer chose, what the customer wrote in their own words, and the range they were shown.

This is the Trust Lab question in a kitchen. The customer’s words, the tool’s suggestions and Jim’s judgment are three different things, so the brief keeps them in separately labelled places.

The 3D is what people see first. What matters is the shop’s own rules sitting underneath it, so a beautiful design can’t quietly become one Jim can’t build.

It grew in phases. The June version was a marketing site with a cost calculator, a free assessment and a plan for automated follow-up. Each phase since has moved more of the conversation into the room itself.

What this page does not claim:

• This is a prototype Jim is reviewing. It is not open to the public; the live demo sits behind a sign-in.
• Planning ranges are guidance, not quotes. The ranges and rules shown are still waiting on Jim’s approval.
• Jim’s own design and manufacturing software stays the authority for what gets built. The site prepares the conversation; it doesn’t replace the cabinetmaker.
• Family work, not client work. No money changed hands.

A working prototype that connects to YouTube data. A viewer chooses the creators who matter to them, and a calm companion sits beside the live stream instead of replacing it.

Underneath, a “receipt” layer. When the viewer asks, StreamScout captures one batch of chat, keeps it in browser memory only, and shows the raw receipt, the parsed records, the privacy rules applied, and the working set as separate stages.

Capability is not permission. An earlier version sorted chat into derived categories like questions and concerns. I pulled that back to a policy gate once I recognised that turning API data into new derived summaries needs explicit validation first.

The interesting engineering was not the AI. It was keeping external data, its state, and its provenance explicit, so nothing quietly became something it was not.

What this page does not claim:

• StreamScout is a personal prototype, not a public product.
• This page does not claim YouTube approval, certification, or policy compliance.
• Derived AI features are held at the gate. They are not shipped.

A local console that takes a legacy artifact (SQL, Python or C++), fingerprints it with SHA-256, and reads it statically. Adding an artifact never runs it.

The same evidence is explained four ways: for the business, for engineering, for a relational thinker, and for an executive. Each explanation stays linked to the exact lines that support it.

Where the code shows behaviour but not reasons, the console says so: behaviour proven, intent unknown.

Readable code is not the same as understandable behaviour. And understandable behaviour is not the same as known intent.

The most useful thing the console does is refuse to fill a gap. An honest “unknown” gives a reviewer something to go and ask about.

What this page does not claim:

• Every artifact in the demo is synthetic: invented companies, accounts and notes.
• It is a prototype for understanding, not a tool for modernising production systems.
• The demo includes my own mapping to a public AI risk framework. That is my reading, not an assessment or certification.

A working prototype that turns a payment ledger into a reviewable journey. Every pattern it surfaces stays tied to the source rows it came from.

Patterns are presented as questions for a human reviewer, not as findings.

A ledger line establishes that the ledger says a payment was applied. It does not, on its own, establish that the payment was applied correctly. Keeping those two apart is most of the work.

The tool surfaces evidence and questions. The person reviewing brings context and decides what happens next.

What this page does not claim:

• The servicer, the borrower and every figure are fictional.
• Nothing here is legal or financial advice, and this page makes no claim that the prototype has been validated on real accounts.