Relayboard

Relayboard doesn’t exist — the operational gap it models does, wherever teams have bolted a chatbot onto processes that were never redesigned around it. Every request, run and audit record in this study is demonstration data. The operating problem is real.

AI isn’t the workflow

A chatbot answering questions is not an operating system.

The impressive part of most AI demos ends at the clever reply. Operations begin after it: someone must turn that reply into a job, a booking, a document, a payment — accurately, repeatably, and in a way a colleague can audit next month.

Relayboard’s premise is a division of labour. The model is one bounded participant inside a larger software system — useful for interpretation and preparation, surrounded by state, permissions, review and evidence. The system owns the truth; the model proposes.

From unstructured input to structured work

Each unit of work follows the same path:

1. Message arrives — an email, a form note, a phone-log summary.
2. Classification — the request is matched to a known workflow type.
3. Extraction — fields are pulled against that type’s schema.
4. Missing context — gaps are surfaced explicitly, never filled by guesswork.
5. Proposed next action — a draft artefact prepared for review, with everything the reviewer needs beside it.

The original source stays available at every step. Any field on the board can be traced back to the words that produced it — which sounds unremarkable until you have tried auditing a system that paraphrased your customer once and kept the paraphrase.

Show your work

Every AI-derived field carries three things: a link back to the source text, a status, and a stated basis.

Status separates what was explicit in the message from what was inferred, and marks what is simply missing. Inference is not treated as a failure — it is treated as information, labelled and priced into the review.

Confidence appears as a plain qualitative label rather than a decimal. Four decimal places of confidence borrow authority from mathematics they cannot claim; a word a human wrote invites the judgement that actually matters.

Nothing enters the business state silently. Interpretation becomes state only when a person moves it there.

Humans own the consequence

The boundary in this concept:

• The model may classify, extract, prepare and draft.
• A human retains authority before any consequential external action — sending, charging, booking, committing.

This is a selected design boundary, not a universal doctrine. Low-stakes domains can reasonably auto-execute some steps. Relayboard imagines communication-heavy operations where a wrong send costs trust, so the gate sits before the action, is owned by a named role, and cannot be bypassed by enthusiasm — the interface offers no path from confident output to sent email without a decision recorded in between.

The broader pattern comes from how competent AI-assisted systems are being built today: bounded responsibilities, human review before consequential action, explicit limits on what the software may read, write and do, defined escalation conditions, and traceable records of approvals, errors and overrides. Those are design positions this concept takes deliberately — engineering choices, not certifications.

Overrides are data

When a reviewer corrects the model, Relayboard keeps both versions: the original proposal and the human correction, together, forever.

Silent replacement is the norm elsewhere — the suggestion simply becomes the value, and the organisation loses the only free training signal it had. Here, an override is a first-class record: what the model thought, what the human knew, and the delta between them.

That serves accountability today and evaluation tomorrow. Patterns across overrides are exactly the material that improves prompts, schemas and routing later — collected by doing the work, not by inventing a feedback programme.

Fail safely

Four situations pause the workflow and escalate to a person instead of encouraging improvisation:

• Missing information the schema requires.
• Low confidence below the workflow’s stated bar.
• Conflict between sources that should agree.
• Action failure when a prepared step cannot complete.

Escalation itself is designed: the pause carries a reason, an owning role and the context needed to resolve it — not an error code dumped at whoever opens the tab. Improvising under uncertainty is how small interpretive slips become consequential mistakes; refusing to improvise is a feature working as intended.

The public demo does not call a model

Stated plainly, because it matters:

The portfolio demo simulates model output deterministically. It contains no model inference. That choice buys four things worth more than theatre:

• Visitor content stays local — nothing typed into the demo is sent to any AI provider.
• Behaviour is reproducible — every visitor sees the same inputs produce the same proposals.
• No keys, no accounts, no metered calls — the demo cannot leak credentials or cost money by being popular.
• Consistency for review — the workflow’s gates, escalations and audit trail demonstrate identically every run.

The architecture separates a ModelAdapter behind a narrow interface. The demo ships a deterministic implementation of that seam; connecting a production, server-side provider later means implementing the same interface — not redesigning the product.

How it would be built

Stated as engineering intent, consistent with how this site ships:

• Static-first Astro shell, with the workspace as the single scripted island.
• A typed canonical workflow model shared by every panel, so classification, extraction and actions reference the same definitions.
• A deterministic mock model adapter behind the narrow interface described above — the seam where a real provider slots in.
• A local workflow state machine that owns stage transitions and enforces approval gates structurally; a locked step is unreachable state, not hidden buttons.
• Idempotent simulated actions, safe to replay on retry without double effects.
• Event/store integration between panels, keeping schedule, queue and record views consistent without reaching into each other’s internals.
• Resettable local persistence — workspace changes survive reloads, stay on the device, and clear on demand.
• Append-only audit records for approvals, errors and overrides.
• A lazy Live Project Player mounting the build through the existing facade — poster until asked, isolated sandboxed frame, ejectable and reloadable.

Why this concept exists

Relayboard demonstrates AI as one bounded participant inside a larger software system — useful for interpretation and preparation, but surrounded by state, permissions, review and evidence.

It also states where we stand on AI work generally. The value of these systems rarely lives in the model; it lives in everything wrapped around it — schemas that admit gaps, gates that hold, histories that refuse to rewrite themselves. That surrounding system is ordinary software engineering done unusually carefully, which is precisely the kind of problem we enjoy.

If your team has a model producing clever output and nowhere trustworthy for that output to go, this page is the shortest possible introduction to how we would build the rest.