BCP

Hosting the manifest

The manifest lives at /.well-known/business.json on the company's canonical domain, served over HTTPS with the right content type and cache headers. DNS verification ties the publishing key to the legal entity. An Ultron-hosted fallback exists for customers who have not verified a domain yet.

Updated today

Canonical location

RFC 8615 well-known URI.

At a glance

Path: /.well-known/business.json
Scheme: HTTPS only. HTTP responses are ignored.
Method: GET. HEAD must return the same headers as GET.
Content-Type: application/ld+json
Encoding: UTF-8. BOM forbidden.
Size cap: 256 KiB. Larger manifests must be rejected by conformant readers.

The path is fixed by RFC 8615 conventions and aligns with the existing well-known URIs other agent protocols use (A2A'sagent.json, OpenID'sopenid-configuration, MTA-STS'smta-sts.txt). Single canonical path. No alternatives, no negotiation.

Warning

Do not host the manifest under /api/,/manifest/, or any custom path. Consumers will not look there. The/.well-known/ prefix is the contract.

Required headers

HTTP semantics for a conformant manifest endpoint.

Header	Required value	Why
Content-Type	application/ld+json (or application/json)	Lets consumers parse without sniffing. JSON-LD is the canonical media type; plain application/json is accepted for compatibility.
Cache-Control	public, max-age=3600	One hour. The manifest is intentionally cacheable so agents do not re-fetch it for every action.
ETag	strong ETag	Allows If-None-Match revalidation. Required for the manifest update flow to work efficiently.
Last-Modified	RFC 7231 timestamp	Allows If-Modified-Since revalidation.
Access-Control-Allow-Origin	*	CORS must permit any origin. Manifests are public by definition.
X-Robots-Tag	noindex (optional)	If you do not want the manifest to surface in search results, set this. Default is to allow indexing.

response examplehttp

1HTTP/1.1 200 OK

2Content-Type: application/ld+json

3Cache-Control: public, max-age=3600

4ETag: "W/\"6a4f-2b1a\""

5Last-Modified: Mon, 19 May 2026 14:30:00 GMT

6Access-Control-Allow-Origin: *

7Content-Length: 7421

9{ "@context": [...], "@type": ["Organization", "BusinessCard"], ... }

Discovery flow

How an agent resolves a domain to a manifest.

01
Normalise the input
Strip protocol, path, port. acme.com, https://www.acme.com/products, mailto:hi@acme.com all reduce to the apex domain acme.com.
02
Probe the apex
HTTPS GET https://acme.com/.well-known/business.json. Follow up to 3 redirects, all must stay on the same registrable domain.
03
Probe www if apex fails
If the apex returns 404 or non-200, try https://www.acme.com/.well-known/business.json.
04
Fall back to the registry
If both fail, query the Ultron BCP registry at https://bcp.51ultron.com/lookup?domain=acme.com. The registry returns either an Ultron-hosted manifest URL or 404.
05
Verify the response
Confirm Content-Type, parse JSON-LD, validate against the schema, check the manifest's domain matches the host. Then run signature verification if a signature is present.

Tip

Steps 2 and 3 should run in parallel with a short race. Most consumers race apex against www and use whichever returns 200 first. Adds zero latency in the common case.

DNS verification

Binding the publishing key to the domain via TXT record.

Anyone with write access to a domain can host a JSON file at/.well-known/business.json. DNS verification proves that the same party also controls the domain at the registrar level, closing the gap between "someone uploaded a manifest" and "the legitimate owner published it."

TXT record format

dns zone (snippet)dns

1_bcp.acme.com. IN TXT "v=bcp1; key=ed25519:7Z9d... ; rotation=2026-05-19T14:30:00Z"

Tag	Required	Meaning
v	yes	Protocol version. Always v=bcp1 for v1 manifests.
key	yes	Algorithm and base64 key fingerprint of the public key used to sign the manifest. Format: <alg>:<base64-fingerprint>.
rotation	no	Last key-rotation timestamp. Optional, useful for diagnostics.
next-key	no	Base64 fingerprint of the upcoming key during a planned rotation. Lets consumers pre-trust it.

Verification algorithm

01
Fetch the TXT record
DNS query for _bcp.<domain> TXT. Use a DNSSEC-validating resolver when available.
02
Parse tags
Extract v, key, optional rotation and next-key.
03
Match the signing key
Compute the fingerprint of the public key the manifest's signature references. It must equal the key tag.
04
Verify the JWS
Run normal JWS verification using the public key resolved from the manifest's signature block.
05
Record verification level
If all three above pass, mark the manifest as DNS-verified. If only the JWS verifies but DNS does not match, treat as advisory L1.

Subdomain rules

When a manifest at acme.com covers shop.acme.com, and when it does not.

The apex manifest is authoritative for the registrable domain and any subdomain that points at it via CNAME or is owned by the same legal entity. The rules are deliberately strict - agent decisions cascade fast, and a confused authority model opens phishing surface.

Scenario	Authoritative manifest
acme.com publishes /.well-known/business.json	Itself.
www.acme.com CNAMEs to acme.com	Inherits acme.com's manifest.
shop.acme.com runs on Shopify and publishes its own	Its own (subdomain wins for itself).
shop.acme.com runs on Shopify, no manifest	Falls back to acme.com only if the shop subdomain is referenced in acme.com's capabilities block.
api.acme.com publishes an A2A agent card but no business.json	acme.com's manifest is authoritative; the agent card is one of its capabilities.
customer.acme.com (vanity subdomain)	Does NOT inherit acme.com. Vanity subdomains must publish their own or are unreachable.

Warning

Inheritance is opt-in. By default a subdomain that does not publish a manifest is not covered by the apex one. This prevents impersonation of subsidiaries the parent never authorised.

Ultron-hosted fallback

Where a customer's manifest lives before DNS is verified.

Most Ultron customers will not have wired a TXT record before they want to be agent-readable. Ultron hosts the manifest at a slug under our own domain and surfaces it through the BCP registry until DNS verification completes.

At a glance

URL: https://ultron.app/c/<slug>/business.json
Lookup: https://bcp.51ultron.com/lookup?domain=<domain>
Trust level: L0 advisory only. Ultron-hosted manifests are signed by Ultron, not by the customer's vLEI.
Promotion: Once DNS verifies, the canonical URL flips to the customer's domain and the Ultron-hosted version 301s to it.

Note

A consumer that finds a manifest at the Ultron-hosted URL via the registry must treat it as L0 (advisory). Promotion to L1 and above requires the manifest to be served from the customer's own domain with DNS-pinned signing key.

Failure modes

What to return when things go wrong.

Condition	Response	Consumer behaviour
No manifest published	404 Not Found	Fall back to Ultron registry. If that also returns 404, treat as no-manifest.
Manifest is invalid JSON	200 with broken body	Consumer must reject. Do not partially parse. Treat as no-manifest.
Signature does not verify	200 with signed body	Downgrade trust level to L0 advisory. Surface a warning in any UI that displays the manifest.
Signing key does not match DNS TXT	200 with valid JWS	Downgrade trust level to L1 (identified, unsigned-by-domain).
Manifest expired (bcp:expires past)	200 with stale body	Re-fetch immediately. If still expired, treat as advisory. Do not act on write scopes.
Endpoint timeout > 5s	-	Abandon. Try www. Then registry. Then fail.
Server returns 5xx	5xx	Retry once with exponential backoff. Then fall back.
Manifest > 256 KiB	200 with oversized body	Reject. Treat as malformed.