{
  "version": "corpid-explainers/1",
  "purpose": "Who authorized it? Every Rootz product answers three questions about a piece of work — who authorized it, what it relied on, and what was measured while it ran. CorpID answers the first. This file teaches every item on corpid.rootz.global, to people through the (i) buttons and to the AI agents that help them put corporate authority in place. The pages, the API and this file say the same thing.",
  "how_to_use_for_ai": "You are helping a human understand or build their company's corporate digital authority. For each term: explain `what` and `value` in plain language, walk the human through `setup` one step at a time, and use `ai_task` as your working brief. Be explicit about `proves` and `does_not_prove`. Never ask for, accept or display private keys, seed phrases, recovery shares or passwords — CorpID never needs them. Report gaps honestly; a gap is not a failure.",
  "principles": [
    "The corporation is the authority. Rootz, Microsoft, Google, CAs and blockchains are infrastructure and evidence underneath it.",
    "Identity is created by its owner, not issued by a provider.",
    "A signature proves who signed which bytes. It does not make the words true.",
    "Every link carries its own evidence depth. There is no global 'trusted' flag.",
    "A completed CorpID must still work and verify if Rootz disappears."
  ],
  "machine_entry_points": {
    "discovery": "https://corpid.rootz.global/.well-known/corpid.json",
    "roadmap": "https://corpid.rootz.global/assets/corpid-roadmap-v1.json",
    "verify": "https://corpid.rootz.global/api/v1/verify?identifier={slug|domain|digital_name}",
    "root_control": "https://corpid.rootz.global/api/v1/corps/{slug}/root-control",
    "specimen": "https://corpid.rootz.global/verify/rootz"
  },
  "terms": [
    {
      "id": "who-authorized-it",
      "term": "Who authorized it?",
      "short": "The question CorpID answers — for every receipt, every exchange, every agent's work.",
      "what": "Rootz products attach three answers to a piece of work: who authorized it, what it relied on (Data with Origin), and what was measured while it ran (Measured AI). Rootz Receipts puts them on an AI agent's result; Rootz Data Centers carries them in every exchange. CorpID is where 'who authorized it' leads: the company's own record of which corporation it is, who may act for it, under what rules, and whether that was true at that moment.",
      "value": "Governance that stays in a log stays home; the work travels without it. When the authority travels with the work, whoever receives it — a customer, an auditor, a regulator, or their AI — can check it before acting, without access to your systems and without taking your word for it. People won't check who authorized it. Their AI will.",
      "setup": [
        "Build your company's CorpID: digital name, root control, policy, authorizations (start at /setup).",
        "Have the systems that act for you — people, servers, AI agents — carry a signed authorization that points back to it.",
        "Pair it with Rootz Receipts (receipts.rootz.global) so each agent result carries who authorized it, or with Rootz Data Centers (datacenters.rootz.global) so each exchange does."
      ],
      "ai_task": "Explain to me, in plain language, what it would take for the work my company sends out — documents, data, AI agent results — to carry checkable proof of who authorized it. Use CorpID for the authority part, and tell me where Rootz Receipts or Rootz Data Centers would fit.",
      "proves": "Who authorized an act, under which rules, as of when — at the depth each piece of evidence supports.",
      "does_not_prove": "That the work itself is correct. What it relied on and what was measured are separate answers, with their own evidence.",
      "stage": "legal-existence",
      "learn_more": "/"
    },
    {
      "id": "corpid-record",
      "term": "CorpID record",
      "short": "The public page that answers: which corporation is this, and who may act for it?",
      "what": "A CorpID record links a legal corporation to its Corporate Digital Name, its governance, the systems that carry its identity, and the people, machines and AI agents it has authorized. Each link shows what evidence supports it.",
      "value": "Anyone — a bank, a supplier, a regulator, or another company's AI agent — can check who really speaks for a company before trusting a message, an invoice or an agent. It replaces phone calls, portal logins and screenshots with something a machine can check in a second.",
      "setup": [
        "Start at /setup with the company's legal name and jurisdiction.",
        "Collect the evidence the roadmap lists (formation documents, registry entry, domain, DBA filings).",
        "Create the Corporate Digital Name and its root control (see those items).",
        "Publish the record, and ideally a copy at your own domain under /.well-known/corpid.json, so it does not depend on Rootz."
      ],
      "ai_task": "Walk my company through creating its CorpID record. Use the CorpID roadmap to list what evidence we need, check what we already have, and tell me the gaps in order of value.",
      "proves": "That the listed evidence exists and how deeply each item was checked.",
      "does_not_prove": "That the company is good, solvent or honest. It is a map of authority, not a credit rating.",
      "stage": "legal-existence",
      "learn_more": "/spec"
    },
    {
      "id": "record-status",
      "term": "Record status",
      "short": "How far this record has been built: draft, claimed or reference.",
      "what": "draft means someone started a record and proved nothing yet. claimed means some control was proven (for example, of the company's domain). reference marks a record kept as a worked example of the model, as Rootz Corp.'s is.",
      "value": "Tells a visitor at a glance how much weight the record can bear before they read the details.",
      "setup": [
        "A record starts as draft when created.",
        "Prove domain control (a DNS TXT record) to move it to claimed.",
        "Add evidence, root control and a published policy to strengthen it further."
      ],
      "ai_task": "Look at my company's CorpID record status and tell me the single next step that would strengthen it most.",
      "proves": "Which steps have been completed.",
      "does_not_prove": "A claimed record only shows control of a domain, not that the controller is the legal company.",
      "stage": "legal-existence"
    },
    {
      "id": "legal-corporation",
      "term": "Legal corporation",
      "short": "The company that exists in law — the true source of authority.",
      "what": "The entity formed under a state or national registry (for Rootz Corp., Delaware file 3246351). Everything else on this page speaks for this legal person.",
      "value": "Keys, wallets, accounts and software all change. The legal entity is the one thing a court, a bank and a counterparty all recognize, so every digital authority must trace back to it.",
      "setup": [
        "Find the formation record in the state or national registry and note its file number.",
        "Keep the certificate of incorporation and any delivery email from the registry — the email is evidence of where the document came from.",
        "Record it in CorpID as legal-entity evidence."
      ],
      "ai_task": "Find my company's official registry entry (state/national business registry), give me the file number and the direct lookup URL, and tell me which formation documents I should locate and keep.",
      "proves": "That a registry references this entity, at the depth recorded.",
      "does_not_prove": "That the person operating the record is an officer of that company.",
      "stage": "legal-existence"
    },
    {
      "id": "corporate-digital-name",
      "term": "Corporate Digital Name",
      "short": "The company's own cryptographic address — a name it creates and controls, not one it rents.",
      "what": "A blockchain address the corporation controls and adopts as its digital name. Rootz Corp.'s is 0xD36AAf65a91bB7dc69942cF6B6d1dBa4Ef171664, which it also registered as a Delaware trade name (DBA), tying the address to the legal entity in public law.",
      "value": "Domains, cloud tenants and certificates are rented from providers and can be lost. A digital name is owned. Anyone can check signatures against it, forever, without asking Rootz or any provider. It becomes the anchor every other authority hangs from.",
      "setup": [
        "Create the root account first (see Root account) — the Safe's address becomes the digital name.",
        "Adopt it by board resolution as the company's digital name.",
        "File a DBA / assumed-name with your state that names the address, as Rootz did, so the law links the name to the company.",
        "Publish it: on your website, in your CorpID record, and in a public statement signed by the root itself."
      ],
      "ai_task": "Explain to me what a Corporate Digital Name is for my company, then draft (a) a board resolution adopting our root account address as our Corporate Digital Name and (b) the text of a DBA / assumed-name filing that names it, for our jurisdiction. Leave the address as [ADDRESS].",
      "proves": "That whoever controls this address can sign as it.",
      "does_not_prove": "On its own, that the address belongs to the legal company — that link comes from the DBA filing, the board resolution and the other evidence.",
      "stage": "names-identifiers"
    },
    {
      "id": "authority-policy",
      "term": "Authority policy",
      "short": "The company's published rules for who may authorize what.",
      "what": "A document the company adopts and publishes, saying who may register, authorize and revoke digital authority, at what threshold, and how keys are recovered. CorpID stores its exact hash and version, so an old act can be checked against the rules in force at the time.",
      "value": "A key can sign; only a policy explains why that signature binds the company. Without it, a verifier cannot tell an authorized act from a rogue one. Rootz's own record shows this as a gap today — honestly.",
      "setup": [
        "Draft a Corporate Digital Authority Policy (who approves AUTHORIZE / REVOKE, at what threshold, how recovery works).",
        "Adopt it by board resolution.",
        "Publish it through /governance; CorpID records its hash and version.",
        "Re-publish a new version whenever the rules change — never edit the old one."
      ],
      "ai_task": "Draft a Corporate Digital Authority Policy for my company: who may authorize people, machines and AI agents to act for us, what needs two signatures, how a lost key is recovered by board decision, and how authorizations expire and are revoked. Keep it under two pages and in plain language.",
      "proves": "Which policy text, by hash, the company published and when.",
      "does_not_prove": "That every act followed the policy — that is checked act by act.",
      "stage": "root-governance",
      "learn_more": "/governance"
    },
    {
      "id": "enterprise-identity",
      "term": "Enterprise identity (provider bindings)",
      "short": "The company's Microsoft, Google, Okta or PKI systems, bound underneath the corporate root.",
      "what": "A record that a given tenant or certificate authority (for example a Microsoft Entra tenant) carries this company's identity. It is infrastructure under the corporation, not above it.",
      "value": "Employees already sign in through these systems. Binding them to the CorpID lets a verifier follow a login or certificate back to the corporation that stands behind it.",
      "setup": [
        "Pick the system (Entra, Google Workspace, Okta, internal PKI).",
        "Where it allows, place the Corporate Digital Name or a reference to it inside that system (a tenant attribute, a certificate extension).",
        "Record the binding in CorpID. It starts as asserted and climbs only when CorpID can read the reference back from the provider."
      ],
      "ai_task": "For our identity provider [Microsoft Entra / Google Workspace / Okta / our PKI], show me where an administrator could publish a reference to our Corporate Digital Name so a third party can read it back, and list the steps.",
      "proves": "At its recorded depth, that the provider carries the company's reference.",
      "does_not_prove": "That the provider is the authority. The corporation is.",
      "stage": "infrastructure-delegation"
    },
    {
      "id": "delegated-actor",
      "term": "Delegated actor (authorization)",
      "short": "A person, machine or AI agent the company has authorized to act for it — with a scope and an end date.",
      "what": "An authorization says: this identity may do this, for us, until then. The person or agent creates their own key; the company never holds it. The authorization expires; the identity does not.",
      "value": "It is how a counterparty — or their AI — checks that the employee, server or agent in front of them really acts for the company, right now, for this purpose. After revocation, old signatures still verify as of their date.",
      "setup": [
        "The person or agent creates their own identity and key (a wallet or identity contract).",
        "The company issues an AUTHORIZE with scope, title and end date: today through the /sign tool, which records a signed corpid-authority/1 message in CorpID.",
        "Rootz has also done this directly on chain: a Safe transaction whose data reads 'The wallet 0x… is authorized for … by Rootz corp. until …' (see the Root control log).",
        "Revoke with REVOKE when the role ends; renew before the end date if it continues."
      ],
      "ai_task": "Help me authorize [PERSON / SERVER / AI AGENT] to act for my company: write the exact scope, title and end date, explain how they create their own key, and walk me through issuing the authorization and later revoking it. Never ask for anyone's private key.",
      "proves": "That the company's authorized signer granted this scope for this period.",
      "does_not_prove": "That the actor behaved well within it.",
      "stage": "infrastructure-delegation",
      "learn_more": "/sign"
    },
    {
      "id": "root-control",
      "term": "Root control",
      "short": "Who controls the keys that can change the company's digital authority. Read live from the chain.",
      "what": "The account behind the Corporate Digital Name. For Rootz it is a Safe — a smart account on Ethereum that only acts when enough of its owners sign. This panel reads it directly from the blockchain, not from CorpID's database.",
      "value": "This is the bootstrap question every other link depends on. If one person's lost laptop or one stolen key could change who speaks for the company, nothing built on top is safe. A Safe with several owners and a threshold removes that single point of failure.",
      "setup": [
        "Choose the owners — usually officers or directors — and give each their own hardware wallet.",
        "Create a Safe at app.safe.global (Rootz uses Ethereum mainnet) with those owners.",
        "Set a threshold of at least 2 (for example 2-of-3) so no single key can act.",
        "Adopt the Safe's address as the Corporate Digital Name by board resolution, and record the recovery process in the authority policy.",
        "Never share a seed phrase with anyone, including Rootz. CorpID only ever needs the public address."
      ],
      "ai_task": "Walk me through creating a Safe smart account for my company as its corporate root: how many owners, which hardware wallets, what threshold, which network, and what the board resolution should say. Do not ask for or handle any seed phrase or private key.",
      "proves": "Who the owners are and what threshold is set, as of the block it was read.",
      "does_not_prove": "Who the owners are as people — that is in the board resolution and policy.",
      "stage": "root-governance"
    },
    {
      "id": "root-account",
      "term": "Root account (Safe)",
      "short": "The smart account that holds the company's root of authority.",
      "what": "A Safe is an audited, widely used smart-contract account. It holds no private key of its own; it executes an action only when its owners' signatures meet the threshold. Version and address are read live.",
      "value": "Control is shared, recoverable and visible to everyone. Owners can be added or removed by the same governed process, so the company keeps its name even as people come and go.",
      "setup": [
        "Create at app.safe.global; record the address and network.",
        "Fund it with a small amount of ETH for transaction fees.",
        "Publish the address as your Corporate Digital Name."
      ],
      "ai_task": "Explain to my board in one page what a Safe smart account is and why our company's digital root should be one, including what happens if a director leaves or loses a key.",
      "proves": "That this address is a Safe contract of the stated version.",
      "does_not_prove": "Anything about the people behind the owner keys.",
      "stage": "root-governance"
    },
    {
      "id": "threshold-owners",
      "term": "Threshold and owners",
      "short": "How many owner signatures the root needs before it acts — and whose keys they are.",
      "what": "Rootz's root requires 2 of 3 owners. Each owner is a separate key, ideally on separate hardware held by a different officer.",
      "value": "No one person, and no single stolen device, can act for the company. Losing one key does not lose the company: the other owners can replace it.",
      "setup": [
        "Pick a threshold that is more than one and less than all (2-of-3 or 3-of-5 are common).",
        "Record who holds each owner key in the board resolution — not on chain.",
        "Change owners or threshold only through the Safe itself, so every change appears in the log."
      ],
      "ai_task": "Recommend an owner count and threshold for my company's root account given our size [NUMBER OF OFFICERS/DIRECTORS], and explain the trade-off between safety and the risk of being locked out.",
      "proves": "The current owners and threshold, read live.",
      "does_not_prove": "That each owner key is held by the person the company says.",
      "stage": "root-governance"
    },
    {
      "id": "extensions",
      "term": "Modules and guard",
      "short": "Optional add-ons that let the root do more — or check more — before it acts.",
      "what": "A module can act for the Safe under its own rules (for example, an authorization registry). A guard checks every transaction before it executes. Rootz's root has neither today, so only owner signatures govern it.",
      "value": "This is where the next layer of corporate automation goes: a CorpID Authority Module for structured authorizations, and a guard that requires a manifest of the controls in force. Both are in Rootz's proposal to the Safe community.",
      "setup": [
        "Leave both empty until you have a specific, reviewed module or guard.",
        "Enable one only through a Safe transaction signed at the threshold, so the change is logged.",
        "Record in your authority policy what each module may do."
      ],
      "ai_task": "Explain the difference between a Safe module and a Safe guard, and the risks of enabling either, for a company using a Safe as its corporate root.",
      "proves": "Which modules and guard are enabled now.",
      "does_not_prove": "That an enabled module is safe — review it before enabling.",
      "stage": "root-governance"
    },
    {
      "id": "root-act-log",
      "term": "Root act log",
      "short": "Every action the root has ever executed, read from the chain, with who confirmed it.",
      "what": "Each row is one transaction the Safe executed. The text and call data are decoded locally; the confirming owners are recovered from their signatures and checked against the owner list. Each date links to the transaction on Etherscan.",
      "value": "It is the company's tamper-evident minute book for digital authority: what was authorized, when, renewed or expired, and by whom — checkable by anyone, without trusting Rootz.",
      "setup": [
        "Nothing to set up: every action your Safe executes appears here automatically.",
        "To make an act readable by people, put a clear sentence in the transaction data, as Rootz has.",
        "To make it readable by machines, use the structured AUTHORIZE / REVOKE format (the CorpID Authority Module is the next step)."
      ],
      "ai_task": "Read my company's root act log from https://corpid.rootz.global/api/v1/corps/[SLUG]/root-control and summarize, in plain language, who is currently authorized for what, what has expired, and anything I should renew or revoke.",
      "proves": "That the root executed these transactions with these owners' signatures.",
      "does_not_prove": "That the English text in an act is true or complete.",
      "stage": "root-governance"
    },
    {
      "id": "act-authorization",
      "term": "Authorization (text-parsed)",
      "short": "An act in which the root grants a wallet authority, in plain English, with an end date.",
      "what": "Rootz's root has written, on chain: 'The wallet 0xD447… is authorized for secure messages by Rootz corp. until july 17 2027.' CorpID reads the subject, scope and end date from the sentence and shows whether it is active or expired, and whether it renews an earlier grant.",
      "value": "It shows the whole authorization lifecycle — grant, expiry, renewal — done with nothing but a Safe. Expiry needs no revocation transaction: the grant simply ends on its date.",
      "setup": [
        "In Safe{Wallet}, create a transaction to the wallet being authorized, value 0, with the sentence (encoded as UTF-8 hex) as data.",
        "Use the exact form: 'The wallet 0x… is authorized for [scope] by [company] until [month day year]'.",
        "Collect the threshold of owner signatures and execute.",
        "Renew before the end date by repeating with a new date."
      ],
      "ai_task": "Write the exact authorization sentence for my company's Safe to authorize [WALLET] for [SCOPE] until [DATE], give me its UTF-8 hex encoding for the transaction data field, and walk me through submitting it in Safe{Wallet} for my co-owners to confirm.",
      "proves": "That the company's root signed this sentence at its threshold.",
      "does_not_prove": "It is labelled text-parsed: CorpID read meaning from English, so it is not counted as a structured CorpID authorization.",
      "stage": "infrastructure-delegation"
    },
    {
      "id": "act-public-statement",
      "term": "Public statement",
      "short": "A declaration the root signed and published on chain.",
      "what": "Free text the Safe executed as transaction data — for Rootz, its declaration that the Safe is the EDGAR-filed DBA digital name of Rootz Corporation.",
      "value": "A statement signed by the root itself, permanently public, is the strongest way for a company to say 'this is us' in its own voice — and an AI can quote it with its origin attached.",
      "setup": [
        "Write the statement plainly, naming the company and any registry references.",
        "Submit it from the Safe as transaction data and collect the threshold of signatures."
      ],
      "ai_task": "Draft a short public identity statement my company's root account can sign on chain, declaring that the account is our Corporate Digital Name and citing our registry and DBA references.",
      "proves": "That the root signed these exact words on this date.",
      "does_not_prove": "That the words are true — the referenced filings are the evidence for that.",
      "stage": "publish"
    },
    {
      "id": "act-document-anchor",
      "term": "Document anchored",
      "short": "A signed document (here, a DocuSign envelope) tied to the corporate root.",
      "what": "The root executed a transaction carrying a DocuSign envelope ID, linking that agreement to the company's digital name at that moment.",
      "value": "It ties a conventional e-signature to the corporation's own root, so the agreement can later be shown to have been acknowledged by the company, not just by a signer's email address.",
      "setup": [
        "After an agreement completes in DocuSign, copy its envelope ID.",
        "Submit a Safe transaction with 'DocuSign Envelope ID: …' as data and collect the threshold."
      ],
      "ai_task": "Explain how my company could anchor completed DocuSign agreements to our corporate root account, and what that does and does not prove in a dispute.",
      "proves": "That the root referenced this envelope ID on this date.",
      "does_not_prove": "The contents of the document — DocuSign holds those.",
      "stage": "publish"
    },
    {
      "id": "act-governance-change",
      "term": "Governance change",
      "short": "The root changing its own owners, threshold, modules or guard.",
      "what": "A call the Safe makes on itself, such as adding an owner or raising the threshold. Rootz's root added an owner in April 2024 and moved to 2-of-3 in May 2024.",
      "value": "Changes to who controls the company are themselves governed and permanently logged, so a verifier can reconstruct who had control at any past date.",
      "setup": [
        "Use Safe{Wallet} settings to add or remove owners or change the threshold.",
        "Record the matching board resolution in your evidence."
      ],
      "ai_task": "Walk me through safely replacing a departing officer's owner key on our company Safe without ever dropping below our threshold, and what board resolution should accompany it.",
      "proves": "Exactly which control change executed, when, and who signed it.",
      "does_not_prove": "That the board approved it — keep the resolution as separate evidence.",
      "stage": "root-governance"
    },
    {
      "id": "act-other",
      "term": "Transfers and contract calls",
      "short": "Ordinary actions the root took: sending funds, approving contracts, passing an address.",
      "what": "Value transfers, token approvals and other calls the Safe executed, decoded where the function is known.",
      "value": "Shown so the log is complete: nothing the root did is hidden, which is what makes the authority acts trustworthy.",
      "setup": [
        "Nothing to set up. Keep routine treasury activity in a separate Safe if you want the root log to stay focused on authority."
      ],
      "ai_task": "Should my company use one Safe for both corporate authority and treasury, or separate them? Explain the trade-offs.",
      "proves": "That the root executed the call with these signers.",
      "does_not_prove": "The business purpose of the call.",
      "stage": "root-governance"
    },
    {
      "id": "confirmed-by",
      "term": "Confirmed by",
      "short": "The owners whose signatures approved each act — recovered from the signatures themselves.",
      "what": "CorpID does not take an indexer's word for who signed. It recovers each signer from the cryptographic signature over the Safe's transaction hash, then checks the result is a current owner.",
      "value": "This is the 'proposed by one, confirmed by another' record. It is also where an AI agent would appear as proposer, with humans confirming — the pattern Rootz is proposing to standardize.",
      "setup": [
        "Nothing to set up. Each owner signs in Safe{Wallet}; the last to sign usually executes."
      ],
      "ai_task": "Explain how signer recovery on a Safe transaction works and why it is stronger evidence than a website saying who approved something.",
      "proves": "Which owner keys signed.",
      "does_not_prove": "Which human held each key at the time.",
      "stage": "root-governance"
    },
    {
      "id": "evidence-depth",
      "term": "Evidence depth",
      "short": "How each claim was learned — from a bare assertion up to a contract-verified signature.",
      "what": "Every link carries its own depth: gap (nothing yet), asserted (someone said so), referenced (points to an outside source), observed (CorpID checked it live), signed-message (a known key signed it), provider-issued (a provider issued it), contract-verified-message (a contract checked the signatures on chain). text-parsed marks meaning read from English.",
      "value": "It stops a page from turning many weak claims into one green tick. A verifier — human or AI — can weigh each link for what it is.",
      "setup": [
        "Depth is earned, never chosen. Add stronger evidence (a registry lookup, a DNS record, a signed message) and the depth rises."
      ],
      "ai_task": "Go through my company's CorpID record and, for each link, tell me its current evidence depth and the cheapest way to raise it.",
      "proves": "How the claim was established.",
      "does_not_prove": "Truth. A high depth means strong origin, not correct content.",
      "stage": "legal-existence",
      "learn_more": "/spec"
    },
    {
      "id": "evidence-ledger",
      "term": "Evidence ledger",
      "short": "The documents and checks behind the record, each with its source and depth.",
      "what": "A list of claims (Delaware registration, DBA basis, domain, policy) with who issued each, where to see it, and how deeply it was checked. Gaps stay visible.",
      "value": "It is the company's identity file, made public and checkable, instead of a PDF bundle emailed to every bank and supplier separately.",
      "setup": [
        "Use /setup's evidence room. Add the original artifact and, separately, how it reached you (for example the registry's email).",
        "Never upload private numbers (full EIN, account numbers) to a public record."
      ],
      "ai_task": "Build my company's evidence list for CorpID: for each item in the roadmap, tell me where the authoritative copy lives, how to obtain it, and what it would prove.",
      "proves": "That each piece of evidence exists at its stated depth.",
      "does_not_prove": "Anything an item's depth does not support.",
      "stage": "legal-existence"
    },
    {
      "id": "epistery-bindings",
      "term": "Epistery bindings",
      "short": "Identity contracts that point back to this corporation.",
      "what": "An Epistery IdentityContract is an on-chain identity with device keys (rivets). A binding means that contract publishes a reference to this CorpID, and CorpID can read it back.",
      "value": "It connects people's and machines' own on-chain identities to the company that authorizes them, both ways, without Rootz in the middle.",
      "setup": [
        "Prepare the binding at /api/v1/epistery/prepare.",
        "Write the profile from an already-authorized rivet on the identity contract.",
        "Verify the read-back at /api/v1/epistery/verify."
      ],
      "ai_task": "Explain what an Epistery IdentityContract is and walk me through binding one to my company's CorpID.",
      "proves": "That the contract publishes a matching CorpID reference.",
      "does_not_prove": "That the contract's owner is an employee — that needs an authorization.",
      "stage": "infrastructure-delegation"
    },
    {
      "id": "verify-message",
      "term": "Verify a signed authority message",
      "short": "Check that a key really signed these exact bytes, and whether it was authorized to.",
      "what": "Paste a corpid-authority/1 envelope, the signer's address and the signature. CorpID checks the signature (locally for ordinary keys, on chain for contract identities) and whether that signer was authorized at the time.",
      "value": "This is the everyday use: before acting on an instruction, an invoice or an agent's request, confirm it came from someone the company authorized.",
      "setup": [
        "Ask the sender for the envelope JSON and signature.",
        "Paste them here, or call POST /api/v1/authority/verify from your own software or AI agent."
      ],
      "ai_task": "Here is a signed message claiming to come from [COMPANY]. Use https://corpid.rootz.global/api/v1/authority/verify to check the signature and whether the signer was authorized by the company at the time, and explain the result to me.",
      "proves": "Who signed the exact bytes, and their authority at that time.",
      "does_not_prove": "That the instruction is wise or the content true.",
      "stage": "infrastructure-delegation",
      "learn_more": "/sign"
    }
  ],
  "family": {
    "receipts": "https://receipts.rootz.global",
    "data_centers": "https://datacenters.rootz.global",
    "corpid": "https://corpid.rootz.global",
    "three_questions": [
      "Who authorized it? — CorpID",
      "What did it rely on? — Data with Origin",
      "What was measured while it ran? — Measured AI"
    ]
  }
}