Ultron as publisher
Every Ultron customer gets a BCP manifest as a byproduct of being on Ultron. We assemble it from data already in their workspace, host it under our domain until DNS is verified, then promote it to the customer's own domain. This is the distribution mechanic that gets thousands of live manifests on the open agentic web without anyone hand-writing JSON.
Publishing model
Zero-config first. Verified second. vLEI-bound third.
| Stage | Trigger | Where the manifest lives | Trust level |
|---|---|---|---|
| Stage 0 - Auto-generated | Customer completes /company-demo header (logo, name, domain). | ultron.app/c/<slug>/business.json | L0 (advisory) |
| Stage 1 - Domain-verified | Customer adds a DNS TXT record proving domain control. | Their own domain's /.well-known/business.json (proxied through Ultron's CDN). | L2 (DNS-pinned signed) |
| Stage 2 - vLEI-bound | Customer connects a vLEI role credential issued by an accredited QVI. | Same URL as Stage 1, signed by the vLEI key. | L3 (vLEI-bound) |
Source data
What signals feed the manifest.
| Manifest field | Source in Ultron |
|---|---|
| identity.legalName | company_profiles.legal_name (from /company-demo header) |
| identity.domain | company_profiles.domain (verified during onboarding) |
| identity.lei | company_profiles.lei (optional, looked up from GLEIF when domain matches) |
| identity.jurisdiction | company_profiles.jurisdiction |
| identity.registeredAddress | company_profiles.address |
| identity.sameAs | Auto-derived from connected integrations (LinkedIn URL, Crunchbase scrape) |
| capabilities.mcpServers[0].url | ultron.app/mcp/<tenant>/ (Ultron-hosted, tenant-scoped MCP server) |
| capabilities.mcpServers[0].scopes | Computed from the workspace's enabled chat-v2 tool subset |
| capabilities.openApi | ultron.app/api/v1/openapi.json (when the customer has API keys enabled) |
| commerce.catalog | ultron.app/c/<slug>/catalog (when the customer has products configured) |
| commerce.pricing | Customer's own pricing page URL (entered manually) |
| commerce.paymentRails[].endpoint | Stripe / Brevo integration metadata |
| policy.allowActions | Workspace policy editor (defaults: catalog.read, pricing.read, contact.send) |
| state.status | Live: derived from health of the customer's tenant resources |
| state.supportContact | company_profiles.support_email + business hours |
Generation flow
What happens server-side when a manifest gets minted.
- 01TriggerEither a workspace mutation (profile edit, integration connect, scope change) or the daily reconciler job at
ultron-cron. - 02AssembleThe publisher reads
company_profiles,workspace_integrations,tenant_mcp_scopes, and current health state from Postgres. - 03Build JSON-LDRun the field map above. Produce a JSON-LD object that conforms to the BCP schema.
- 04Canonicalise and hashApply JCS to the body without the signature block. Compute SHA-256. Compare against the previously-stored content hash to short-circuit no-op republishes.
- 05SignIf the workspace has a pinned signing key, sign the JCS body with ES256. Stamp
signedAt. If no key (Stage 0), skip signing. - 06Store and serveWrite the manifest to
bcp_manifestswith the content hash, JCS bytes, and signature value. Set the Last-Modified header for the next GET. - 07Optional: push to customer domainFor Stage 1 / Stage 2, the same artefact is reverse-proxied at the customer's
/.well-known/business.jsonvia Ultron's CDN.
Domain verification
Promoting a manifest from Stage 0 to Stage 1.
Customer-side TXT record
The customer is shown a unique key pair generated for their workspace. They publish the fingerprint as a DNS TXT record at_bcp.<domain>. The exact format mirrors what every modern DNS verification flow already does (Brevo, SendGrid, Cloudflare, Google Workspace).
Server-side verification check
Once the customer clicks "Verify", Ultron resolves the TXT record from a DNSSEC-aware resolver, parses the tags, and compares the published fingerprint against the workspace's pinned key. On match, the workspace flips to Stage 1 and subsequent manifests are signed with the verified key.
Promotion path
Where the manifest is served at each stage.
Update cadence
When the manifest is re-signed and re-served.
| Trigger | Latency |
|---|---|
| Customer edits company profile (name, domain, address, support contact) | Immediate. Manifest re-minted within the same request, signed, ETag rotated. |
| Customer connects or disconnects an integration that changes scopes | Immediate. |
| Customer changes policy block (allowActions, rateLimit) | Immediate. |
| Customer rotates signing key | Immediate, with a 24-hour DNS overlap window per the rotation flow. |
| State changes (incident open / closed, support hours edit) | Immediate. |
| Background reconciliation (no profile changes) | Daily, idempotent. Content hash short-circuits no-op republishes. |
| bcp:expires approaching | Auto-renewed 24 hours before expiry. expires advances 30 days from now. |
state.incidentWebhookfor push notifications. The webhook fires on incident create / update / close events with the new manifest URL, so downstream agents do not need to poll.Diagnostics
Customer-facing observability for the publisher pipeline.
Every workspace gets a dashboard surface at/dashboard/settings/bcp showing the current manifest stage, last sign timestamp, DNS verification status, public manifest URL, and a "View raw manifest" link. If verification fails, the dashboard surfaces the diff between expected and actual TXT record so the customer can fix it without us guessing.
- Customer dashboard
/dashboard/settings/bcp- Manifest preview
/dashboard/settings/bcp/preview- Verification logs
- Last 30 days of TXT-resolve attempts, signed by trace id.
- Sign history
- Last 50 sign events with timestamp, kid, content hash.
- Admin diagnostic
/admin/bcp/<tenant>(Ultron staff only). Full pipeline state.
Where this lives in the codebase
File map for the publisher pipeline.