Projects¶
A project is the main container for a body of editorial processing. It keeps a team's flows, runs, source articles, extracted evidence, and settings together so that one project cannot accidentally mix operational data with another.
When you query Backfield API, you're always asking about
a specific project, identified by its slug (a short, URL-friendly name like
general).
What lives in a project¶
| Area | What it holds |
|---|---|
| Flows | The pipelines you build in Agate |
| Runs | Each time a flow is executed on your text — see Runs |
| Processed items | The reviewable results of a run — see Processed items |
| Content | The articles and extracted details produced by runs — see Data model |
| Stylebook | The shared catalog assigned to the project for confirmed people, places, and organizations |
| Settings | Project-level choices for AI models, integrations, webhooks, and API keys |
How projects relate to the rest of Backfield¶
- A project belongs to one organization, optionally grouped into a workspace.
- A project draws on shared organization settings such as models and integrations, and is assigned one same-organization Stylebook. That Stylebook is authoritative for every flow and entity operation in the project.
- Access is granted per project, so different teams can work in different projects without seeing each other's data. See Users & access.
Flows, runs, and processed items¶
These terms describe different levels of the same work:
- A flow is the reusable recipe: the steps Agate should perform.
- A run is one execution of that recipe.
- A processed item is the result for one article within the run.
A batch run therefore has one run record and many processed items. Editing a flow changes future runs; it does not rewrite runs that already finished.
The project's Stylebook¶
When a project is created, it is assigned one Stylebook from the same organization. Every flow in the project uses that Stylebook for canonical people, organizations, and locations. The assignment is shown in project settings and cannot be changed later.
Several projects may share one Stylebook. In that case, they contribute separate article evidence to the same canonical reference catalog. Filters in Stylebook let editors narrow mentions and candidate work by project without changing Stylebook-wide canonical metadata or connections.
Project overview and settings¶
The project page brings together its flows and runs and summarizes activity such as article counts, processed items, and estimated AI cost. Overview statistics show average AI cost and processing time per processed item, with flow-level breakdowns aligned to that view.
Below the summary cards, tabs organize day-to-day work:
| Tab | What it shows |
|---|---|
| Flows | Reusable pipelines for the project |
| Runs | Current and past executions, with pagination when a project has many runs |
| Articles | Processed items across runs; search by headline or URL to open review without knowing the originating run |
| Models | Project model choices and the assigned Stylebook |
| Integrations | Project-specific credential overrides |
| API | Project API keys for external applications |
Project settings also show:
- the assigned Stylebook;
- project-specific model and integration choices;
- a project system prompt that supplies shared model guidance where supported;
- project API keys for external applications;
- project webhooks that send signed notifications to external systems.
Organization defaults reduce repeated setup, while project overrides let a team use a different approved model or integration credential where supported.
Organization administrators can delete a project from its card on the workspace or project page. Deletion removes the project's flows, runs, articles, and API keys. Shared Stylebook records are kept. You must type the project name exactly to confirm. The organization's default project cannot be deleted.
The project slug¶
Every project has a human-readable slug, unique within its organization. Different organizations may use the same project slug. You'll use it when calling the API:
You can find your slug in the project's settings, or confirm it with the Get project endpoint.
A project API key is bound to one project. Backfield API resolves that binding before validating the slug, so a matching slug in another organization cannot redirect the request.