Sites
The Sites studio publishes a single-page website to your whole organization — a title, a few text sections, and a data table — that teammates open in an ordinary browser to confirm, edit, or add rows. Every action comes back with a name on it, and syncs into your app so your local copy stays the source of truth. It's the tracking-sheet replacement: one card, one click, and the whole org has a page to fill in.
"Here are the AWS tags Finn pulled — confirm yours or fix the name." That's a site. You build the table from real data a specialist pulled, publish it with a click, and each teammate signs in once and updates their rows. The edits flow back as an attributed change log — who confirmed what, and when — so you're never chasing a spreadsheet around email again.
◧ Publish to the org
A page with sections and a table, live in a browser for everyone in your org.
◧ They fill it in
Teammates sign in once and confirm, edit, or add rows themselves.
◧ Everything attributed
Each change is recorded against the contributor's verified identity.
◧ Syncs back to you
The change log folds into your app — your local copy stays authoritative.
What it is#
A site is a small published page — a title, a few prose sections, and one data table — that lives on Zimac's central sites service so the whole org can reach it from a browser. It exists to replace the tracking sheet: the shared list you send around to have people confirm their tags, sign off on a migration, or fill in the owner column. Instead of a spreadsheet with no memory of who touched what, a site attributes every edit and reports it straight back to you.
Publishing a site#
You publish a site the way you send anything outward in Zimac: a specialist stages a confirmable card showing exactly what will go live — the title, the sections, and every row of the table — and you click Publish. Nobody can publish on your behalf, and the table is built from real data (yours, or a pull from someone like Finn), never invented rows.
How teammates contribute#
Everyone in your organization opens the site in a normal browser and signs in with a single click (their Zimac account, with a paste-a-seat-token fallback). From there they can confirm a row as correct, edit its values, or add a new row — no app install, no account setup. It's the low-friction surface that makes people actually respond: click the link, fix your line, done.
Statuses, attribution & sync#
Every row carries a status that moves as people act on it:
Each action is attributed server-side to the contributor's verified identity — not something they type, but who they actually signed in as — and recorded in a per-site change log. Your app pulls that log down and folds it in, so the Sites studio shows the authoritative rows, their statuses, and a "who did what" activity feed ("Drew confirmed a row · 2h ago"). Because the sync is one-way into your app, your local copy stays the source of truth, and it's offline-safe.
What a site shares#
A site is deliberately different from the rest of the team layer. Signals, Broadcasts and Asks are end-to-end encrypted envelopes the server can't read; a site is meant to be readable by the whole org from a browser, so it lives on a service that stores and serves its content. Same trust root — the same organization sign-in gates it — but a different disclosure contract, which is why the rule is simple:
Tracking contributions#
Once a site is live, you can ask how it's going and get the real state: each site's title and live URL, the row-status tallies (how many pending, edited, confirmed), and the most recent attributed contributions. It's how you answer "who's confirmed their tags?" or "what's still pending?" without opening the page — the studio keeps the last synced state, and a Sync pulls the very latest.