Developers · AAES Govern · Appearance

Operator console
appearance.

Set dark or light mode, four colors, a font family, and an image logo. Your operator can also install a fuller theme file. AAES Govern runs on your infrastructure.

This page describes AAES Govern’s controls. AAES Operate has private-work permissions, operational reviews and recorded-spend limits; it does not include Govern. About AAES Govern

Settings appearance

This page applies to the AAES Govern operator console. It does not describe AAES Operate.

Open Settings > Appearance in the operator console to set dark or light mode, four colors (accent, background, surface, text), a font family, and an image logo. Administrators save settings for the whole tenant; individual users do not have separate saved themes.

The console is served by the AAES Govern process on its separate operator listener. The font field names a sans-serif font family, such as Inter, sans-serif. It uses fonts available on the user's system and does not download a font file.

Appearance routes

These routes belong to the operator console listener. They are not part of the daemon API contract, and they are not available at AAES_ENDPOINT.

Operator appearance endpoints
Method and routeBehavior
GET /api/themeReturns the per-tenant theme JSON. Returns 404 if no theme store exists.
GET /api/settings/appearanceReturns the appearance settings used by the Settings editor, based on the stored tenant theme.
POST /api/settings/appearanceSaves the administrator's appearance changes. Include the current revision with the update; an outdated revision returns 409 so another administrator's changes are not overwritten.

Settings editor document

This example shows the appearance fields edited in Settings. To save an update, use the operator API's request format and include the current revision. This example is not a complete POST request or a theme file installed by provisioning.

{
  "appearance": "dark",
  "accent": "#9295eb",
  "bg": "#08090a",
  "surface": "#101113",
  "text": "#f1f2f3",
  "font_sans": "Inter, sans-serif",
  "logo": {
    "data_url": "data:image/png;base64,...",
    "alt": "Organization logo"
  }
}

Use a PNG, JPEG, or WebP logo, including an image encoded as a data URL. SVG is refused because it can contain executable markup.

Provisioned theme file

Your operator can install a theme file with additional colors, optional font-file URLs, and a logo path under /tenant-assets/. Font files and these managed assets must be installed during provisioning; the Settings editor does not upload them. The example below is a theme file, not an appearance-update API request.

{
  "version": 1,
  "appearance": "dark",
  "colors": {
    "bg": "#08090a",
    "surface": "#101114",
    "surface2": "#18191d",
    "text": "#f2f2f4",
    "muted": "#b4b5be",
    "dim": "#858792",
    "line": "rgba(255,255,255,.08)",
    "accent": "#9295eb",
    "accent-soft": "rgba(146,149,235,.12)",
    "ok": "#91c8aa",
    "warn": "#d6bd83",
    "bad": "#dc9292"
  },
  "fonts": {
    "sans": {
      "family": "system-ui",
      "url": null
    },
    "mono": {
      "family": "monospace",
      "url": null
    }
  },
  "logo": {
    "url": "/tenant-assets/logo.png",
    "alt": "Organization logo"
  }
}

A null font URL selects the family's system stack. A non-null font URL must point at a managed asset under /tenant-assets/.

Managed assets

Provisioned font and logo URLs must point to files under /tenant-assets/{name}. External CDNs and path traversal are refused. Assets are placed by provisioning.

  • GET /tenant-assets/{name} serves the managed file.
  • Asset requests require operator authentication.
  • A theme asset URL is not a public, unauthenticated asset endpoint.

Not implemented

Custom domains, certificates, branded login, and embedding are not implemented. Theme support does not establish those integrations. Evidence provenance and verification keys remain identifiable when presentation is customized.

Scope a white-label evaluation with the surfaces and deployment model you need.

Build your own UI

Build an agent-facing interface against the daemon's OpenAPI 3.1 contract and the Go, Python, or TypeScript SDKs.

Daemon callers use AAES_ENDPOINT and present an operator-issued bearer token through AAES_TOKEN. The credential resolves the tenant. For /v1/action and /v1/brokered, request bodies include tenant_id and actor_id claims that must match the authenticated caller; the SDKs fill them. Other operations derive identity from authentication and may reject these fields. Follow each operation's schema.

A full administrative replacement needs the separate operator-session API, role checks, and CSRF protection. Agent SDKs do not provide policy publication, identity administration, or every console workflow.

Keep console JSON routes out of this integration contract. Routes such as /api/approvals, /api/spend, /api/records, and the appearance routes above belong to the operator console listener, not the daemon API.

Remaining integration notes ship with the evaluation package. Do not infer an appearance revision field or write payload from the theme example.

Need appearance integration details beyond this reference? Contact hello@aaes.ai.