Engine Passport

This specification is published under CC BY 4.0: implement it, fork it, ship it — attribution to "MostlyNo Engine Passport" is the only ask. Version 1.0 describes what is deployed today; breaking changes will bump the major version and never rewrite already-signed receipts. A live machine-readable example of everything below: /e/1/passport.json.

Scope honesty: a passport proves technical facts — a deployment exists, exposes a declared read-only interface, and answers a fixed benchmark consistently. It never proves investment quality or performance, and no tier or label may be presented as if it did.

• engine — a deployed service that analyzes securities and answers over MCP (Model Context Protocol).
• manifest — the engine's self-declared JSON contract (§2). Always labelled SELF_DECLARED.
• verification run — one recorded MCP session in which the verifier observes the engine (§3).
• receipt — the signed, append-only record of one verification run (§5).
• passport — the public page + JSON projection combining manifest, fingerprints, tier, and receipts.
• anchor — the receipt's existence proof in an external public transparency log (§6).

A single JSON document, max 32,768 bytes, schema_version: "0.1". Structural validation is strict — unknown keys are rejected. Top-level objects:

• engine — slug (kebab, 3–40 chars), name, description, version, optional version_source (github_commit + repository + commit, or none).
• owner — display_name, optional github_login, optional opt-in public_contact, optional built_with_ai / ai_stack.
• strategy — families, markets (US · EU · UK · JP · KR · CA · AU · OTHER), asset_classes (equity only in v1), optional horizons, sectors, universe description.
• protocol — name mostlyno-engine, version 0.1, transport remote_mcp, authentication none | bearer.
• capabilities — tools list — must include engine.describe, engine.health, engine.analyze.
• permissions — reads list; writes MUST be []; money_authority MUST be false.
• forbidden_capabilities — must enumerate the full canonical forbidden list: place_order, cancel_order, read_broker_account, read_private_portfolio, withdraw_funds, execute_shell, arbitrary_file_read, network_proxy. Declaring any of these as a tool rejects the manifest.
• decision_contract — decision vocabulary drawn from BUY · RESEARCH · WATCH · PASS · AVOID · INSUFFICIENT_DATA (INSUFFICIENT_DATA is mandatory — an honest engine must be allowed to say "I don't know"), output_schema mostlyno-valuation-output-v0, data_as_of_required and engine_version_required both true.

The invariants are the point: a conforming manifest cannot declare write access or money authority — the schema makes the unsafe thing unrepresentable rather than merely discouraged.

One ordinary MCP client session against the declared endpoint, recorded in full:

1. initialize (protocol 2025-06-18), then tools/list — the observed tool set is recorded and fingerprinted.
2. engine.describe and engine.health — the run fails if the health-reported version disagrees with the manifest.
3. engine.analyze across a fixed benchmark ticker list (§4), each name twice: outputs must validate against the declared schema and repeat within tolerance — a stochastic answer is not analysis.
4. Three fingerprints are computed: manifest hash, capability fingerprint (the tool set), output-schema fingerprint (the decision contract).
5. The result is recorded as a receipt (§5), signed, and anchored (§6).

Only these calls are made. The verifier holds the endpoint URL (and optional bearer token) for the duration of one run; nothing about the engine's per-ticker outputs is published.

Benchmarks are fixed per market and chosen by the verifier, never by the engine — an engine that picks its own exam proves nothing. Current sets: US (10 US large caps), KR v0 (10 KOSPI large caps), and KR v1 (the deeper Korea exam: large-cap anchors plus KOSPI/KOSDAQ mid and small caps, ending in a listed SPAC shell as an honesty probe — the only right answer on it is INSUFFICIENT_DATA). Deeper benchmarks are optional new exams, never moving goalposts: a tier earned on an earlier set stays valid. Every receipt records its benchmark_id; a tier earned on one market is never presented as earned on another.

Tiers: REJECTED · CONNECTION_VERIFIED · SCHEMA_ONLY · SCHEMA_VERIFIED. Trust labels accumulate evidence: CONNECTION_VERIFIED, VERSION_CLAIM_CONSISTENT, SCHEMA_VERIFIED, SCHEMA_STABLE. Lifecycle: CURRENT → STALE (a new version shipped) or REVOKED. Verification is one-time per version; nothing needs to stay up afterward.

A receipt is a JSON payload plus a detached JWS. Payload fields include: receipt_type, attribution (engine, version, strategy ids), platform_observed_at, benchmark_id, the three fingerprints, observed_engine_version, verification_status, tier, trust_labels, source_observation (each claim marked observed or not — unverified claims are stated as unverified), and bounded sandbox counts (substantive answers, repeats, request transcript hash). Receipts are append-only: corrections are new receipts, never edits.

Canonicalization: JSON with object keys sorted lexicographically at every level, no insignificant whitespace, finite numbers only, -0 serialized as 0 (RFC 8785-compatible for this value domain). Signature: detached JWS, ES256 (P-256), protected header {alg, kid, b64:false, crit:["b64"]}; signing input is base64url(header) + "." + canonical(payload). Verification keys are published at /.well-known/mostlyno-jwks.json and old keys remain listed after rotation.

A registry that signs its own receipts could backdate them. To close that hole, the sha256 of each receipt's canonical payload is submitted to Sigstore Rekor — a public append-only transparency log operated outside MostlyNo — as a hashedrekordentry (the artifact is the canonical payload; the entry carries its sha256, an ECDSA signature over the payload bytes, and the platform public key). The log's integratedTimeis an existence proof nobody — including the registry — can move earlier. Only the hash and signature leave the registry: receipt contents are never uploaded, so a creator's delete-on-request still holds.

Each anchored receipt exposes transparency_anchor in passport.json: provider, log entry UUID, log index, integrated_at, payload sha256, and a public lookup URL.

1. Fetch passport.json; take connection_receipt.payload and detached_jws.
2. Canonicalize the payload (§5) and verify the JWS against the JWKS — this proves who signed and what was signed.
3. sha256 the canonical payload and look it up in the transparency log via transparency_anchor.transparency_log_url — this proves by when it existed.

All three steps use public data and standard tooling; none require asking MostlyNo for anything.

Reference implementation, registry, and verifier: mostlyno.com. The format is free to implement — a competing registry that adopts this spec is a feature, not a threat, because anchored history (§6) makes every registry's age independently checkable. Questions and proposals: hubadmytroo@gmail.com.