A consulting engagement produces a surprising amount of material in a short time: a calendar of sessions, recordings and transcripts, summaries and digests, documents that get signed off, decisions, action items, the client's own obligations, a measurement panel, and at the end a readout. Before Pavilion that material lived in a Zoom account, a shared drive, a chat channel, and whoever's inbox the acceptance email landed in. Nothing tied it together, nothing told the client what had been agreed and when, and nothing could be handed over cleanly at the end.

Pavilion is the room those things are discussed and accepted in. A pavilion is a structure built for one occasion and handed over when the occasion ends, which is exactly the shape of the thing: one workspace per engagement, instantiated from a template, run for two or six weeks, closed with a complete export, and then either kept readable indefinitely or deleted on the client's request with proof that nothing remains.

Pavilion workspace overview for the StrataForge Robotics engagement
The workspace overview: the engagement's stages from the template, what needs attention, the next session, the deliverables count, and the most recent published record.

Five laws, enforced by structure

Pavilion is hosted by Renkara rather than installed in the client's environment, and what makes that acceptable is a small set of laws that are enforced by the database and the architecture rather than by discipline.

One workspace, one tenant. Every table with workspace-scoped rows carries the workspace id, PostgreSQL row-level security is armed on every request from the caller's membership, and the only cross-workspace view — the consultant's list — shows no content. A client role reaching for another workspace gets a 404, not a 403, because a caller who may not act on an object learns nothing about whether it exists.

Reviewed before visible. Agents draft session summaries, decisions and action items from transcripts, but nothing they draft reaches a client until a consultant has accepted, edited or rejected each item and published the set — one transaction, one audit event. Draft invisibility is enforced at four independent layers, so a bug in one cannot leak a draft.

Immutable once published. Document versions, decisions, acceptances, measurement snapshots, exports and audit events are never edited or deleted. A BEFORE UPDATE OR DELETE trigger refuses the change whether it comes from the application, a migration or a psql session. Corrections are new rows.

Everything is audited, including every read of a document, recording, transcript or export by a client member or guest, written in the same transaction as the change it records. The sponsor gets their own side of the log: what their people and their guests saw, and when.

The export is complete. Anything a client can see is in the export, in open formats, and a feature that stores something the export cannot represent does not ship.

The export verifies itself

The last law is the one the product is built around. Closing a workspace generates an archive: every document as PubMark source and as the printed PDF, every transcript as VTT and JSON, published summaries and digests, the decision log, tasks, obligations, deliverables with their acceptances, the members list, the calendar, the audit log as JSONL, the measurement snapshots, every attachment, and every recording in its own media archive — with a manifest at the root that lists every file, its size, content type and SHA-256, and the object it came from.

Then Pavilion reads the archive back. It parses the manifest out of the written zip and recomputes every hash from the zip's own bytes, refusing any file the manifest does not list. A hash merely remembered from the write would prove nothing. Only an export that survives that is offered for download, for a window, with every download audited.

Pavilion Handover page
The Handover page: request an archive of the record so far (an interim archive of an open workspace is labeled as such). Every file is listed with its SHA-256 hash, and the archive verifies itself before it is offered.

Templates, schedules, obligations

The two engagements Pavilion was built for — a two-week Assessment and a six-week Embed — are data, not code. A template version carries the weeks with their themes, the sessions and their preferred days, the deliverables and the evidence rules that satisfy them, the document slots, the client's obligations per week, and the measurement plan. Instantiating one lands sessions on business days in the client's time zone around its holiday list.

Obligations are the client's side of the bargain: repository access by a date, engineer hours per week, a sponsor's presence at the readout. Hours are computed from attended pairing sessions rather than typed in; a missed access obligation slides the whole schedule by business days with the cause visible on the calendar, the obligations page and the measurement gate's basis.

Sessions, documents, acceptance

Recordings arrive from Zoom, are scanned and transcribed, and the transcript reader scrolls with the player in both directions. Documents are PubMark versions with paragraph anchors that survive a new version, a diff, a print stylesheet and a PDF rendered by the same engine the reader uses. A sponsor accepts a version by a recorded statement carrying the exact text shown, the version's hash, the address and the time — there is no MCP tool for acceptance and no agent path, because it is a person's act.

Pavilion document reader
The document reader: immutable versions, the acceptance record with its SHA-256, and comments.

Retention, deletion, guests

Everything is kept until the client asks otherwise. A consultant can set a media purge after 90, 180 or 365 days with the sponsor's agreement recorded — who agreed, and how — and the closing export keeps the media so the client's copy is unaffected. An owner can place a legal hold that suspends every purge and deletion. Deletion is two-step: a sponsor requests it on a closed workspace, an owner confirms, a seven-day cooling period runs with a final export offered first, and one organization-level record with counts remains. A test proves that nothing bearing the workspace id survives, in the database or the bucket.

Guests are not members. A share link opens exactly one document version, recording or session page, read-only, with expiry, an optional passcode with a lockout, a maximum number of uses and revocation — and every use recorded with its address and browser.

107 MCP tools

Every capability of the API is an MCP tool, proxying the REST API in-process so authorization is identical whether a person clicks or an agent calls. An API key names the agent and the person it acts for, bound to one workspace with scopes; the feed and the log render "Claude Code for Charles Sieg", and a missing scope is named in the error rather than hidden behind a 404. When drafting runs outside the service, a queued draft simply waits for an agent session to submit it through the same review gate.

Pavilion runs at pavilion.app.renkara.com; the bare pavilion.renkara.com is its marketing site. It is the first fleet tool built on that convention.