> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tied.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Resolution pricing
> Seven classes, each assigned by a single mechanical test evaluated against the action audit trail.
Every billable resolution is assigned exactly one class, and the class sets the orchestration fee. There are seven classes. **Six are derived**: each is decided by a **discriminator**, one mechanical test evaluated against the action audit trail with no interpretive step. The seventh, `long_horizon_case`, is **designated by contract** and has no derived test.
A discriminator is only worth publishing if you can apply it yourself. Every test below can be checked against the action records for your own conversations, and you should reach the same class we did.
**Class prices the outcome. It never gates access.** What your agent can do is set by the tools and
integration scopes you have connected, applied at the point of action. The class is worked out
afterwards and used only to price what happened. No class has to be purchased, unlocked or
entitled.
This page documents each discriminator exactly, the order they are evaluated in, what modifies a fee, and four worked examples. The confirmation signals that decide whether a resolution bills at all are on [What counts as a resolution](/pricing/resolutions), and the published rates are in [How pricing works](/pricing).
## The seven classes
| Class | What it means | Exact discriminator, as a test on the audit trail | Fee |
| - | - | - | - |
| `knowledge` | Answered from the knowledge base, without touching any connected external system. | No successful action call is recorded for the resolution. Knowledge-base retrieval does not go through the action system, so it never counts. | **\$0.35** |
| `read` | Looked something up in a **connected external system** to answer, as distinct from reading its own knowledge base. | At least one successful action call with `mutates = false`, and no successful call with `mutates = true`. | **\$0.50** |
| `write_simple` | Changed something, but no money moved: an unlock, an address change, a booking, a ticket. | At least one successful call with `mutates = true`, none with a `financial`, `phi`, `pci` or `sox` compliance class, written to fewer than three distinct providers. | **\$0.70** |
| `write_financial` | Moved money: a refund, credit, charge, or billing-impacting plan change. | At least one successful call with `mutates = true` and `compliance_class = financial`, and none of the higher tests below met. | **\$0.95** |
| `orchestrated` | Coordinated a multi-system outcome. | Successful calls with `mutates = true` that name a provider, spanning **three or more distinct providers**. Nothing else counts: no approval, no escalation, no other condition. | **\$1.90** |
| `compliance_gated` | Changed something holding regulated data: PHI, cardholder data, or SOX-scoped records. | At least one successful call with `mutates = true` and `compliance_class` in (`phi`, `pci`, `sox`). Regulated **reads** stay `read`. | **Coming soon**, not sold and not priced |
| `long_horizon_case` | A case running weeks or months across many conversations. | **None derived.** Designated by contract, never assigned from the audit trail. It is the only class that is available under an Enterprise contract alone. | Billed as a case, set in the contract |
### Worked examples of each
*"What's your return window?"* → answered from the knowledge base. Nothing queried, nothing changed.
*"Where's my order?"* → agent reads the order record and the carrier's tracking status, then reports back.
Customer is locked out → agent resets the account state in the identity provider; customer logs back in.
Damaged item → agent verifies the order and issues the refund at the processor; the refund settles.
Enterprise account escalation → agent writes to the CRM, the billing system and the ticketing system in a single resolution.
A months-long claim, dispute, onboarding or collections case with negotiated milestones and a terminal state.
## `compliance_gated` in detail
**Not available today.** A HIPAA BAA, a PCI Level 1 attestation and a SOX instrument are on the
roadmap and none is held today, so the class is **not sold, not priced and not purchasable on any
plan**. Nothing is currently classified into it.
It is **unreachable rather than merely unpriced**: a `phi`, `pci` or `sox` action is
[refused outright at the action primitive](/agents/actions) until the matching executed
compliance instrument is recorded on the account. The gate is the instrument, never the plan.
Three properties of the discriminator, stated because each is a common misreading:
**It is set by a successful mutating call, not by whether a gate passed.** The class attaches to what was done, not to which controls ran.
**A blocked action does not produce this class.** If a compliance gate blocks an action, that action never executed — so the resolution is classified by what it actually achieved, most often `knowledge` or `read`.
**A regulated read stays `read`.** The premium attaches to acting on regulated data, not to looking at it.
**`pci` attaches only when Tied's own action handles cardholder data.** A refund executed at a
payment processor is `write_financial` at \$0.95, not `compliance_gated` — the processor holds the
card number and Tied refunds against a token, so no cardholder data is in Tied's scope. Ordinary
refunds never derive `compliance_gated`, and neither does any other action where the card data
stays with the processor.
## `long_horizon_case` in detail
This class is **assigned by contract, not derived**. A case is designated under an Enterprise
contract, and the audit trail is never used to decide that a conversation is a case. No derivation
test is published for it because none exists, and a test invented for it would be a label rather
than a test.
A conversation inside a designated case does **not** bill as a resolution at all. No class fee, no
orchestration fee. The **case** is the billing unit instead. A conversation is billed either as a
resolution or inside a case, never both. See [Long-horizon cases](#long-horizon-cases).
## Two class rules
**Rule 1 — the highest class reached wins, and it bills once.** A resolution that reads an order,
checks a policy, and then issues a refund is **one** `write_financial` resolution at \$0.95. Not a
`read` plus a `write_financial`. Not three charges.
**Rule 2 — a failed write does not move the class in either direction.** Every test is evaluated
over calls that actually **succeeded**.
An attempted refund that errors at the processor is not a `write_financial`. The failed attempt
also does not disqualify the resolution from a lower class: a resolution that looked something up
and then tried unsuccessfully to write is a `read`, and prices as one.
## Evaluation order
Every test runs over calls that succeeded. A write attempted and not completed moves the class in
neither direction.
`compliance_gated` → `orchestrated` → `write_financial` → `write_simple` → `read` → `knowledge`.
`long_horizon_case` is never derived. A conversation inside a case designated by contract bills
inside the case, not as a resolution, so no class is derived for it.
## The class is derived, not asserted
Tied does not label a resolution's class by judgement, by model output, or by anyone's assessment after the fact. **Six of the seven classes are derived mechanically from the action audit trail** — the signed record of every read and write the agent performed, which system it touched, and whether it succeeded. The seventh, `long_horizon_case`, is set in your Enterprise contract rather than derived.
The agent emits the audit references. It does not emit a class, does not see the class it will be assigned, and structurally cannot influence its own price tier.
The six derived discriminators above are therefore not descriptions of how classification is attempted. They are the predicates actually evaluated, in the order listed.
The consequence: the class on an invoice is **derivable from the receipt** without asking Tied. If the trail shows no successful monetary write, `write_financial` cannot be billed.
**Class is a price key, never a permission.** No authorization path reads the class to decide
what a tenant may do. Capability is gated by [tool scope](/agents/actions), at the point of
action. The class is worked out afterwards and used only to price what already happened.
## Plan availability
**Tools gate capability; class only prices the outcome.** The one enforceable gate is your per-tenant tool and integration scope, applied at the point of action: if a system is not connected, or is connected read-only, the agent cannot act there and the attempt never happens.
| Plan | Tool scopes | Reachable classes |
| - | - | - |
| **Starter** | No integrations. Knowledge-base retrieval still works, because it is not a system touch. | `knowledge` |
| **Business** | Read-only scopes. The agent can look into connected systems to answer, but changes nothing. | `knowledge` · `read` |
| **Advanced** | Write scopes, with narration and rollback. | `knowledge` · `read` · `write_simple` · `write_financial` · `orchestrated` |
| **Enterprise** | Write scopes plus a contract. | All of the above · `long_horizon_case` |
Read the middle column as scopes rather than entitlements. A class is reachable **because** the tenant holds the scopes named; buying a plan does not buy a class, and granting a scope is what makes a class reachable.
**`orchestrated` is not an Enterprise class.** It is reachable at Advanced, because it is three or
more of the writes Advanced already holds. A twelve-person brand with Shopify, Stripe and Loop
connected reaches three providers on one routine *"refund this, cancel the subscription, update my
address."*
**Approvals are not part of the discriminator.** While an approval limb existed, switching on an
approval chain raised the price of every approved action — a governance control acting as a price
increase. It was removed. `orchestrated` is purely a count of distinct providers successfully
written. Approval chains remain an Advanced capability and do not change what a resolution costs.
### On Enterprise, the discriminators are a starting point
If *moves money* or *regulated data* means something specific in your industry, that definition is written into your contract. Once written, it is evaluated against the audit trail the same mechanical way — a negotiated definition is still a discriminator, not a judgement call.
Negotiated per-class rates are applied as an override **after** the published-rate lookup. The published rate table stays free of tier and contract data, and no enterprise per-class figure appears on any customer-facing surface.
## Long-horizon cases
Some work is not a resolution. A claim, a dispute, a complex onboarding, a collections process, a multi-week investigation: these run for weeks or months, across many conversations, with progress rather than completion for most of their life.
**Long-horizon cases are billed as cases, not as resolutions.**
| Component | Detail |
| - | - |
| **Case fee** | Drawn at negotiated milestones. Milestones are defined per contract against the shape of the work |
| **Completion bonus** | A **fixed amount**, not a percentage, on reaching the terminal milestone. The trigger is a provable fact rather than a negotiation |
**Case pricing replaces per-resolution pricing for the work your contract designates as a case.**
The terms are negotiated per contract, so the exact structure is the one your contract states.
## Void windows
A billed resolution is not final. Two triggers void it and credit it back automatically:
* **The same issue reopens within 30 days.**
* **Negative feedback, retroactively, with no time limit.** A rating given long after the resolution still voids it.
The mechanics, the timing and what the credit covers are on [The money-back guarantee](/pricing/guarantee). How a reopen is matched to the original is on [What counts as a resolution](/pricing/resolutions#void-windows).
## Worked examples
Four end-to-end walkthroughs. Model costs shown are illustrative of real magnitudes; the receipt carries the exact figure.
**Conversation.** *"How long do I have to return something?"* The agent answers from the
knowledge base with the return window, condition requirements and how to start a return.
Customer: *"Perfect, thanks."*
| Determination | Value | Because |
| - | - | - |
| Class | `knowledge` | **Zero tool calls other than retrieval.** The trail contains no external-system reads and no writes. |
| Signal tier | **Tier 1 — explicit confirmation** | The customer stated the outcome. |
| Orchestration fee | \$0.35 | `knowledge` rate. |
| Model cost | \$0.0021 | Passthrough at provider rate, zero markup. |
| **Total billed** | **\$0.3521** | |
**Conversation.** *"Where's my order? It was supposed to be here Tuesday."* The agent reads the
order record and the carrier's tracking status, and replies with the real status, revised
delivery date and a tracking link. The customer opens the tracking link and does not reply
again.
| Determination | Value | Because |
| - | - | - |
| Class | `read` | **At least one non-retrieval read, zero successful writes.** Two external reads (OMS, carrier). |
| Signal tier | **Tier 3 — corroborated silence** | Substantive answer ✓ · no negative signal ✓ · corroborator = **the tracking link was opened** ✓. Without the opened link this resolution would **not** bill. |
| Orchestration fee | \$0.50 | `read` rate. |
| Model cost | \$0.0047 | Passthrough at provider rate, zero markup. |
| **Total billed** | **\$0.5047** | |
**Conversation.** *"My order arrived damaged, I want a refund."* The agent reads the order,
reads the returns policy, confirms eligibility, and issues a \$48.00 refund at the payment
processor. The refund settles. No chargeback follows.
| Determination | Value | Because |
| - | - | - |
| Class | `write_financial` | **At least one successful write that moves money.** Two reads *and* a settled refund. **Highest class reached wins** — this bills **once**, as financial. |
| Signal tier | **Tier 2 — system-verified outcome** | The refund **settled** at the processor with no chargeback. The customer was not asked. |
| Orchestration fee | \$0.95 | `write_financial` rate. |
| Model cost | \$0.0113 | Passthrough at provider rate, zero markup. |
| **Total billed** | **\$0.9613** | On a \$48.00 refund handled end to end without a human. |
**Conversation.** *"I need to change the shipping address on order 4471."* The agent reads the
order, confirms it has not shipped, and asks the customer to confirm the new address before
writing it. The customer never replies. The address is never changed.
| Determination | Value | Because |
| - | - | - |
| Class | **None assigned** | It was heading for `write_simple`, but a never-attempted write does not set the class — and no class is assigned to a non-billable resolution. |
| Signal tier | **Tier 0 — never billable** | Reason code `abandoned_mid_flow`. The work the agent did is not relevant to the test. |
| Orchestration fee | **\$0.00** | No resolution was recorded. |
| Model cost | \$0.0039 | The tokens were consumed: the agent read the order, checked the shipment status and composed a reply. Passthrough at provider rate, no orchestration fee on top. On BYOK this never appears on a Tied invoice. |
| **Total billed** | **\$0.0039** | The token cost alone. |
### Why an unbilled resolution still shows a model cost
The two numbers are independent.
The **orchestration fee** is what Tied charges for resolving something. It is \$0.00 in the fourth example because nothing was resolved.
The **model cost** is what the provider charged for tokens the conversation consumed. Those tokens were consumed regardless of outcome. On Tied-supplied keys that passes through at the provider rate with no orchestration fee on top; on BYOK the provider bills you directly and it does not appear on a Tied invoice at all.
A real provider charge is not zeroed out to make the receipt tidier — the receipts are the audit surface, and one that omits a cost that was incurred is not auditable.
## Next
The four signal tiers, the ten never-billable conditions, and the void windows.
What triggers an automatic credit, when it arrives, and why there is no cap.
What other per-resolution vendors publish, with sources and check dates.
The full mechanism, including reconciliation and zero-balance behaviour.
The audit trail the class is derived from.
The tool scopes that decide which classes are reachable.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.