Using the QueryLayer workspace

This is the operator guide for the admin workspace you reach at https://your-site.example/admin/. For installation, see install.md. For the data model behind what you see, see ../docs/publishing-contract.md.

#Roles

Role is enforced twice: the UI hides what you cannot do, and the database (row-level security) refuses it even if something else asks.

#The one rule to understand

Saving is never publishing. Every save creates a new immutable revision. Publishing is a separate, deliberate act that can be immediate or scheduled. Every mutation — human or agent — is recorded in an append-only audit trail with who, what, and when. You can always roll back to an exact revision.

#The sidebar

#Content → Pages

The content inventory. Each row is a page with a path (for example /whole-house-generators/), a status (draft, published, archived), and its draft/published pointers.

The editor fields:

• Title, path, excerpt, markdown body — the content itself.
• SEO title, SEO description, canonical URL, robots — revision-scoped metadata. Publish preflight refuses publication when these are incomplete.
• Template — which code-owned editorial template renders the page.

Buttons worth knowing:

• Save creates a new immutable revision (revision 1, 2, 3…). Nothing goes live.
• Preview opens the exact draft revision — what you see is what would publish, rendered through the same markdown pipeline as the public site.
• Publish queues an immediate publish job. Publishing advances the published pointer, records the job, and dispatches a site rebuild to your delivery provider (see Publishing).
• Schedule queues publication for a future time.
• Unpublish / Rollback are also publish jobs, with the same audit trail.

#Content → Revisions

The full history: every revision of every page, who or what created it, and its relationship to the current draft and published pointers. Restore proposals start here. Revisions cannot be edited or deleted — only superseded.

#Content → Content Imports

Bring in existing content (for example from a legacy CMS) through a governed migration: source URL crawl, field mapping, destination rules, a quality preview, and an import plan. The plan creates staged records only — nothing becomes live content until the normal revision and publish gates are passed.

#Search

• Search intelligence — 28-day versus previous-28-day performance from connected sources, with tabs for internal links, entities, analytics, AI visibility, citability, outcomes, and answerability. Requires the search integrations.
• Topical map — one intended owner for every query you care about. Nodes carry intent, entities, parent relationships, and lifecycle state. Only a published page can put its node into the published state, so the map never lies about what is actually live.

#Evidence

The claim ledger. A claim is a factual statement pinned to one exact immutable revision; evidence is a preserved source excerpt with an explicit support verdict attached to that claim. Scheduled source monitoring re-checks evidence and surfaces changes for human review. Agent-found claim candidates appear as candidates only — they never affect publishing until a human records them deliberately.

#Publishing

The execution ledger: every publish, unpublish, rollback, and schedule job, with its status, preflight result, and delivery outcome. Two useful distinctions:

• Published means QueryLayer advanced the immutable pointer. That always succeeds or fails on preflight, before any external system is touched.
• Delivered means your static-site provider rebuilt. Delivery has bounded retries and its own status. With no delivery provider configured, content still publishes internally and delivery records the reason it did not run.

The Agent-run gate panel chooses which agent-run outcomes must stop a revision before it can publish. Every policy change creates a new immutable policy version.

#Inbox

Private contact-form submissions for this site. Payloads are visible only to human site members, are never in public APIs or logs, and are deleted automatically after the form's retention window. Accepted submissions also produce a durable notification delivery (see integrations for Resend). Export is available as JSON or CSV.

#Agents

Everything about governed automation:

• Agents — stable identities (human-created) with site-scoped permissions.
• Connections — expiring, revocable bearer grants per agent. Creating one shows one-time credentials and the exact commands for Codex, Hermes, or any MCP client. See agent-onboarding.md.
• Agent runtimes / Site agents — for Hermes users: pair a local Hermes runtime, bind native sessions, and assign profiles to the site.
• Approvals — durable decision cards. When an agent proposes a mutation, it lands here; nothing executes until a human decides.
• Tasks / Triggers — durable work items and the schedules or events that initiate them (including search-decay and index-gap triggers). Agents claim tasks, work them, and return governed outcomes; maximum two automatic retries per step.

#Integrations (admins only)

Per-connection surfaces for Google Search Console, Bing Webmaster Tools, IndexNow, and the static-site deployment connection. Step-by-step setup lives in integrations.md.

#Templates, Team, Settings

• Templates — the versioned, site-scoped template contracts revisions bind to. Components stay code-owned; this view is the audit surface.
• Team — memberships and roles for the installation's organization.
• Settings — site configuration and the read-only update status.

#Governance for agents, in one box

Autonomous planning orchestrates.
Typed governed proposals authorize mutations.
Server-side execution performs approved mutations.

Agents can read what their scopes allow and can propose work. Every consequential mutation flows through a typed proposal with risk classification and a human approval card. Approved work executes server-side, producing immutable executions and audit records. Agents never hold database credentials, never gain authority by wording, and cannot publish autonomously unless you explicitly configure that policy.

#Everyday loop

1. Draft or revise a page (immutable revisions accumulate).
2. Preview the exact revision.
3. Publish (immediately or scheduled) — watch the job in Publishing.
4. Keep claims honest in Evidence; watch performance in Search.
5. Let agents propose the boring work; approve what deserves it.