# Cortex Licenses

Cortex Licenses make data, API, compute, content, and report rights readable by agents. They do not replace Stripe, AWS Marketplace, x402, or a provider's API-key system. They add a canonical license record that agents can verify before paying or using a resource.

## Why Cortex Licenses Exist

Payments answer only one question: did money move? Agentic commerce needs a second answer before the agent can safely use what it bought: what is the agent allowed to do with the result?

That gap matters most when agents buy data, reports, API output, content, compute results, or enrichment from third-party providers. A human can read a terms page and make a judgment call. An agent needs a structured record it can evaluate automatically:

- Can this report be used in commercial output?
- Can this dataset be analyzed but not redistributed?
- Can this response be used for model training?
- Is the license tied to a specific quote or receipt?
- Has the right expired or been revoked?
- Which wallet, agent, merchant, service, and asset does the entitlement belong to?

Cortex Licenses give both sides a shared machine-readable artifact for those questions. The provider publishes canonical license JSON, Cortex stores and indexes it by hash, and the agent checks the hash before use.

## Who Benefits

**AI agents and agent operators** get a pre-use safety check. Before summarizing a paid report, training on a dataset, enriching a customer record, or sending output to a client, the agent can call `check_license` and get a deterministic allow/deny decision with reasons.

**Data and API providers** get a lightweight entitlement record without rebuilding their billing stack. They can keep Stripe, AWS Marketplace, invoices, x402, API keys, or their own account system, then publish a Cortex license after payment so agent buyers know what rights were granted.

**Marketplaces and facilitators** get a neutral proof layer between payment and fulfillment. A payment facilitator can settle the payment, while the license hash records the post-payment usage rights the agent should respect.

**Enterprise buyers** get cleaner audit trails. A procurement, compliance, or security team can ask not just "what did the agent buy?" but "was the agent allowed to use it this way?" The quote, receipt, fulfillment, and license hash form an evidence trail.

**Merchants selling high-value digital goods** get a practical path to agent buyers. Agents are more likely to buy when they can inspect rights, expiration, attribution requirements, redistribution limits, and model-training restrictions without human review.

## Why We Built It

Cortex already binds merchant identity, quote terms, payment policy, receipts, fulfillment, disputes, and trust signals. Licenses complete the loop for digital and information goods.

Without licenses, an agent can prove it paid and received something, but not whether it can lawfully or contractually use the output in the intended context. That is a blocker for agentic commerce in data-heavy workflows: enrichment APIs, research reports, market intelligence, legal or compliance datasets, generated media, paid content, and proprietary compute outputs.

The design is intentionally boring:

- Rights are structured enough for agents to check.
- The canonical hash is stable enough to bind into quotes, receipts, and attestations.
- Providers keep their existing payment and access-control systems.
- The license check is available over REST and MCP, so both apps and agent runtimes can use it.
- NFT minting can come later as a wallet/display layer without replacing the canonical license document.

## Seller Flow

1. Register a merchant and service in `CommerceRegistry`.
2. Publish a service catalog that describes payment rails and available license tiers.
3. After payment or entitlement creation, publish a `cortex.license.v1` document with `POST /licenses`.
4. Bind the license hash into quote terms, a receipt, or an attestation.
5. Call `POST /licenses/check` from the fulfillment system before serving protected data.

## Buyer Flow

1. Discover a service and license tier.
2. Compare rights and constraints against local policy.
3. Pay through the allowed rail: direct transfer, facilitator, x402, AWS, Stripe, or invoice.
4. Store the returned `license_hash` in the agent's inventory.
5. Before using the data, call `check_license` over MCP or `POST /licenses/check`.

## License Document

```json
{
  "schema": "cortex.license.v1",
  "issuer": "0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
  "holder": "0x1111111111111111111111111111111111111111",
  "merchant_id": "1",
  "service_numeric_id": "1",
  "service_id": "company-enrichment-v1",
  "asset_id": "dataset:company-enrichment:v1",
  "quote_hash": "0x1111111111111111111111111111111111111111111111111111111111111111",
  "receipt_id": "42",
  "rights": ["read", "analyze", "commercial_output"],
  "constraints": {
    "commercial_use": true,
    "derivative_use": true,
    "model_training": false,
    "redistribution": false,
    "attribution_required": true
  },
  "expires_at": 1798761600,
  "terms_uri": "https://provider.example/terms/company-enrichment-v1"
}
```

The canonical document hash is the license id. Use it as a quote `termsHash`, fulfillment evidence hash, or attestation `dataHash` when a stronger binding is needed.

## Current Minting Model

V1 licenses are not NFTs. A license is "minted" by publishing canonical `cortex.license.v1` JSON through `POST /licenses`; the returned `license_hash` is the stable license id.

That choice is intentional for the current product:

- License rights are usually holder-specific, scoped, expirable, and sometimes revocable.
- Agents need a deterministic allow/deny check more than they need a transferable wallet collectible.
- The same license hash can be bound into quote terms, receipts, fulfillment evidence, or attestations without adding another onchain transaction.

NFT or SBT minting remains a later option. If added, it should be a thin `LicenseRegistry`/token wrapper that points to the canonical `license_hash`; the document and `check_license` decision remain the source of truth.

## API

### `POST /licenses`

Stores canonical license JSON and returns the hash, URI, and indexed fields.

```json
{
  "license_json": "{\"schema\":\"cortex.license.v1\",\"issuer\":\"0x...\",\"holder\":\"0x...\",\"rights\":[\"read\"]}",
  "expected_hash": "0x..."
}
```

### `GET /licenses`

Lists indexed licenses. Filters: `holder`, `issuer`, `merchant_id`, `service_numeric_id`, `asset_id`, `active`, `limit`, `offset`.

### `GET /licenses/:hash`

Returns the canonical JSON bytes for a license.

### `POST /licenses/check`

Checks whether a license covers a proposed use.

```json
{
  "license_hash": "0x...",
  "agent": "0x1111111111111111111111111111111111111111",
  "action": "commercial_output",
  "quote_hash": "0x...",
  "receipt_id": "42",
  "context": {
    "commercial": true,
    "model_training": false,
    "redistribution": false,
    "derivative": true
  }
}
```

Response:

```json
{
  "license_hash": "0x...",
  "allowed": true,
  "checks": [
    { "name": "active", "passed": true, "detail": "license is active" },
    { "name": "action", "passed": true, "detail": "action commercial_output is included in rights" }
  ]
}
```

## MCP Tools

`list_licenses` returns license inventory for an agent, issuer, merchant, service, or asset.

`check_license` returns the same allow/deny decision as the REST endpoint and is the preferred agent pre-use check.

## V1 Boundaries

The API evaluates structured rights and common constraints. It rejects rights outside the V1 vocabulary and constraint fields agents cannot deterministically evaluate. It does not interpret arbitrary prose terms, meter usage, or enforce offchain access by itself. Providers should still enforce API keys, rate limits, and account state in their own fulfillment systems.