The Tenor platform is a multi-tenant hosted service at api.tenor.run that evaluates contracts and executes operations against live entity state. It separates the read path (evaluation) from the write path (execution), giving you advisory analysis locally and authoritative state management in production.

Evaluator vs Executor

Tenor has two runtime modes. Understanding the distinction is critical to using the platform correctly.

Evaluator (Read Path)

The evaluator is open source, runs locally or embedded via SDKs, and is purely advisory. Given a contract, a set of facts, and entity states, it computes:

• Verdicts — the named Boolean or typed conclusions produced by rules
• Action space — the complete set of operations each persona can legally perform right now
• Provenance — the chain of reasoning from facts through rules to verdicts

The evaluator is a pure function: same inputs always produce same outputs. It never writes state, never contacts external systems, and never has side effects. You can run it in CI, in tests, in browser WASM, or in a serverless function.

# Local evaluation — pure computation, no network
tenor evaluate escrow.tenor --facts facts.json --entities state.json

{
  "verdicts": {
    "payment_ok": { "value": true, "stratum": 0 },
    "eligible_for_release": { "value": true, "stratum": 1 }
  },
  "action_space": {
    "escrow_agent": ["release_funds"],
    "buyer": ["dispute_transaction"],
    "seller": []
  }
}

Executor (Write Path)

The executor is the commercial hosted runtime at api.tenor.run. It does everything the evaluator does, plus:

• Loads entity state from a managed Postgres database
• Applies snapshot isolation so concurrent operations never see partial state
• Executes operations atomically — persona check, state check, precondition check, effects, all in one transaction
• Records provenance — every state change is traced back through verdicts, rules, and facts
• Enforces the executor obligations (E1-E20) that guarantee correctness

The executor is the authoritative source of truth. When your application calls POST /{org}/{contract}/flows/{flow_id}/execute, the executor loads current state, re-evaluates the contract, verifies the operation is legal, applies effects, and commits — all atomically.

# Remote execution — atomic, authoritative, provenance-recorded
curl -X POST https://api.tenor.run/acme/escrow/flows/release_flow/execute \
  -H "Authorization: Bearer tk_live_abc123" \
  -H "Content-Type: application/json" \
  -d '{"persona": "escrow_agent", "facts": {"release_approved": true}}'

Executor Obligations (E1-E20)

The executor guarantees twenty behavioral invariants. These are not aspirational; they are verified by the conformance test suite and hold for every evaluation and execution.

ID	Obligation	Summary
E1	Snapshot isolation	Every evaluation sees a consistent point-in-time snapshot of entity state
E2	Atomic execution	Operation effects either all apply or none apply
E3	Persona verification	The requesting identity must map to an allowed persona
E4	State precondition	Every entity must be in the expected from_state before transition
E5	Rule precondition	The operation's precondition verdict must be present and true
E6	Provenance recording	Every state change records the full chain: fact -> rule -> verdict -> operation
E7	Deterministic evaluation	Same contract + same facts + same state = same verdicts, always
E8	Stratum ordering	Rules evaluate in stratum order; no rule sees verdicts from its own or higher strata
E9	Closed-world facts	Only declared facts are accepted; undeclared inputs are rejected
E10	Type enforcement	Every fact value matches its declared type; no coercion
E11	Transition legality	Only declared transitions are permitted; the entity FSM is enforced
E12	Terminal state finality	Entities in terminal states cannot transition further
E13	Flow DAG enforcement	Flow steps execute in declared order; no cycles
E14	Handoff authority	HandoffSteps transfer authority to the declared persona
E15	Parallel join semantics	Parallel branches must all complete before the join step proceeds
E16	Error contract fidelity	Failed operations return the exact error message from the error_contract
E17	Idempotent evaluation	Re-evaluating without state changes produces identical results
E18	Audit completeness	Every API call is logged with timestamp, persona, inputs, and outcome
E19	Version pinning	A deployment is pinned to a specific contract hash; no silent changes
E20	Rollback on failure	If any effect in an operation fails, all effects in that operation are rolled back

Multi-Tenancy

The platform is organized around three levels:

Organizations

An organization is the top-level billing and access boundary. Each org gets:

• Its own API key namespace
• Its own set of deployments
• Its own usage metering
• Isolated entity state (no cross-org data access)

API Keys

Keys are scoped to an organization and carry permissions:

tk_live_abc123def456  — production key for org "acme"
tk_test_xyz789ghi012  — test key for org "acme" (separate state)

Production and test environments are fully isolated. Test keys cannot read production state and vice versa.

Deployments

A deployment binds a specific contract version (identified by content hash) to an organization. When you deploy, the platform:

1. Receives the compiled contract artifact
2. Verifies the content hash
3. Runs the elaborator (all eight static checks S1-S8)
4. If all checks pass, activates the deployment
5. Subsequent API calls evaluate against this exact contract version

tenor deploy escrow.tenor --org acme --env production

Deploying escrow.tenor to acme/production...
  Contract hash: sha256:9f4a2b...
  Static checks: S1 ✓ S2 ✓ S3 ✓ S4 ✓ S5 ✓ S6 ✓ S7 ✓ S8 ✓
  Deployment ID:  dep_20260215_001
  Endpoint:       https://api.tenor.run/acme/escrow
  Status:         active

Persona Mapping

The platform maps external identities (API keys, JWT claims, OAuth tokens) to contract personas. This mapping is configured per deployment:

{
  "persona_map": {
    "escrow_agent": ["tk_live_agent_key", "role:escrow-admin"],
    "buyer":        ["tk_live_buyer_key", "role:customer"],
    "seller":       ["tk_live_seller_key", "role:merchant"]
  }
}

When an API call arrives, the platform resolves the caller's identity to a persona before evaluation. If no mapping exists, the call is rejected with 403 Forbidden.

Metering

Usage is tracked per organization per day across five dimensions:

Metric	Unit	Description
Evaluations	count	Each call to evaluate (verdicts + action space)
Flow executions	count	Each call to execute a flow step or complete flow
Simulations	count	Each dry-run simulation (evaluate without committing)
Entity instances	count	Peak active entity instances in a billing period
Storage	bytes	Postgres storage for entity state and provenance records

Usage data is available via the management API and the Tenor dashboard.

Pricing

	Free	Pro	Enterprise
Organizations	1	Unlimited	Unlimited
Contracts per org	1	Unlimited	Unlimited
Evaluations/month	1,000	Unlimited	Unlimited
Flow executions/month	100	Unlimited	Unlimited
Entity instances	100	Unlimited	Unlimited
Storage	100 MB	10 GB included	Custom
Environments	Test only	Test + Production	Test + Staging + Production
Support	Community	Email	Dedicated + SLA
SSO/SAML	No	No	Yes
Audit log export	No	Yes	Yes + SIEM integration
Uptime SLA	Best effort	99.9%	99.99%

The Free tier is enough to develop, test, and prototype contracts locally and against the hosted evaluator. Pro unlocks production execution and unlimited scale. Enterprise adds organizational controls, compliance features, and guaranteed availability.