Reference overview

The rest of the documentation teaches. Reference confirms. When you already know what a flow is and you need the exact name of the status it lands in, when you are writing a custom role and need the precise scope that gates an action, when you are sizing a plan and need the real cap on flow runs per day, this is the section you open. Every page here is a set of tables, each value read from the product itself, so you can settle a question in one lookup instead of inferring it from prose.

In one line: seven catalogs in three groups, plus a glossary, every value read from the live product. Concepts and task guides teach; this section is where you confirm an exact name, scope, cap, or count.

That division of labor is deliberate. The concept pages explain why the platform is shaped the way it is, the task guides walk you through doing the work, and Reference holds the flat, exhaustive lists that would clutter those pages if they tried to carry them inline. A guide tells you a plan has a type; the work items reference lists all seven and what each is for. A guide tells you a role grants permissions; the scope catalog names every one. Read the guide to understand the idea. Come here to get the value right.

How to read these pages

A few conventions hold across the section, and knowing them up front saves you second-guessing a table.

• Every value is current-state, read from the product. These catalogs describe what Disco Parrot does today, not a specification it is built toward. A count, a cap, or an enum can change as the product changes, and when it does, the page changes with it. Treat a number here as the current answer, not a contract.
• Plan-gated and entitlement-gated values say so. Where a capability depends on your commercial plan or on a specific entitlement, the table names the gate. A feature you do not see may be one your plan does not include, and the reference is where you check which.
• Absent and zero are not the same. In a quota table, a missing cap means the capability is uncapped and a cap of zero means it is turned off. A blank cell is never an oversight; it is a value with a meaning, and the page tells you which.
• Anything not yet shipped is flagged as such. Where a value exists in the model but the surface for it has not landed, or where a capability is a plan line item rather than a working flow, the page tells you plainly. The reference does not present a planned thing as a present one.
• The reference points back to the depth. Each catalog links to the concept or task page that explains the entries. The scope catalog links to roles and permissions, the status tables link to workflows, and so on. The table is the lookup; the link is the why.

One lookup, start to finish

An example of the section doing its job. An administrator is writing a custom role for a teammate who should be able to read the audit trail but never export it, and needs to know which scope gates each half of that.

They check the scope catalog and find two scopes in the audit area: audit.read, marked low, which lets a member see the activity feed and the audit log, and audit.export, marked elevated, which is the one that produces a signed evidence package. The danger levels confirm the shape of the decision: reading is routine, exporting is the weightier grant. Back in the role editor, they select audit.read, leave audit.export off, and the question is settled. No guessing which permission the export button checks, and no granting a heavier scope than the task needs.

That is the whole pattern. A precise question, a table that already holds the answer, a danger level that tells you what you are handing over, and a link back to roles and permissions when you want the why behind it.

What is in Reference

The section is organized into three groups, from the records you work with to the caps the platform enforces.

The work model

Access control

Plans, platform, and limits

If you would rather see every term defined in one place first, the glossary is the A-to-Z, and core concepts at a glance is the same set grouped by neighborhood with a link to each full guide.

There is no public API today

It is worth stating plainly, because it shapes how you automate against the platform. Disco Parrot does not publish a public, stable API. Every server endpoint lives under an internal /__ path prefix, and those paths are the private contract between the product's own front end and its own server. They are not versioned, not documented for outside callers, and free to change as the product changes. Nothing in this reference describes a surface you are meant to call directly over HTTP.

That is not a missing piece so much as a different shape. When you want the platform to do work on a schedule or in response to an event, you do not reach for an API client. You build the automation inside the product, out of three pieces:

• Flows orchestrate agent work into ordered, checkpointed steps, and run on a schedule or from a trigger.
• Skills package a repeatable kind of work into a named, reusable action the agent can run.
• MCP tools connect the external systems you want the agent to reach, so a run can act on them.

A few narrow endpoints are reachable from outside, and none of them is a way to script your work. The platform answers a health check so its host can tell it is ready. A self-hosted sandbox operator uses an identity and token exchange to connect and prove who it is. An inbound webhook receiver is the address GitHub calls to report a pull request's status. A public contact endpoint sits behind the sales form. None of these reads or writes your work model, and none is a general API. If a public API ships one day, it will arrive as a documented surface of its own, and you will find it here.

Why the reference is shaped this way

A reference is only worth opening if every number on it is true. So the whole section is built on one rule: every value is grounded in the product as it actually behaves, and where the product and an older intention disagree, the product wins. That is why the pages flag a planned capability as planned and a current cap as current, rather than smoothing the two together into copy that reads well and ages badly. A reader who has to wonder whether a table is aspirational has lost the one thing a reference is for.

Keeping the lookups separate from the teaching pays off both ways. The concept and task pages stay readable because they are not carrying a fifty-row table mid-paragraph, and the catalogs stay complete because they are not trying to also be a tutorial. You can hand a teammate the scope catalog when they are building a role and the reviewable autonomy page when they are trying to understand the model, and each one does its job.

For a new user, the page to start with is the glossary. When a term in another page is unfamiliar, settle it here in one line, then click through to the full guide for the depth.

For a power user, Reference is the fastest path to an exact value. The work items reference and statuses pages are the ones you will return to when you are configuring workflows or building a filtered view that keys off a precise field.

For an administrator, the scope catalog, built-in roles, and plans, entitlements, and quotas pages are the working surface behind a custom role, a plan decision, or a quota you are trying to explain to a team that just hit one.

For an enterprise reviewer, the reference is where claims become checkable. A control you read about in security and governance resolves here to something you can hold up against the product: a named scope with a danger level, a quota with an enforced cap, a delivery mode in the secret policy matrix. The model stops being a description and becomes a list you can audit.