Knowledgebase

The Knowledgebase is your account's record of what it does with Faraday and why. It has two parts:

• The account overview: who your business is, what it is trying to achieve, and why it uses Faraday.
• Use cases: one for each problem Faraday solves for you, saying what the problem is, how Faraday solves it, and the technical details of the data and delivery involved.

Faraday reads it, too. Each use case you save is reviewed to check that it says enough. An adequate use case can then produce a provisioning guide for setting up a new client, or be checked against your account's configuration in an audit.

Find it under Knowledgebase in the Dashboard, or work with it through the API or the MCP server. Everything in it is visible to everyone on your account.

The account overview

Write the overview as plain prose about your business, independent of Faraday:

• Who you are. What you sell, to whom, at what scale, and how you make money.
• Your goals. What you are trying to achieve over the next six to twelve months.
• Why Faraday, why now. What prompted the work, and what you tried before.

Use cases

Write one use case per problem. If two pieces of work use different data, integrate differently, or produce different results, they are two use cases, even when they share a theme.

Give each a specific title in the present tense, such as "Purchase propensity score for email send suppression" rather than "Prediction model". If the work is proposed rather than built, say so in the title.

The preface

• Background: your situation before Faraday, specifically. Which tool, process, or person made the decision, and how often?
• Problem: what that cost, with a number where you have one: a rate, a cost per lead, hours, revenue.
• Solution: what you can do now that you couldn't before, and the measure that will show it worked.

Technical details

This is what Faraday builds from, so be exact. Write "not yet known" rather than guessing.

• Integration: the data sources, with their exact columns and what a row is (a person? an order? a visit?), whether identity fields are plain or hashed, the IDs that identify a record, and whether results are delivered in batches or looked up in real time. For batch delivery, say where the results go.
• Configuration: anything that isn't obvious from the data. For a prediction, what is being predicted and for whom. For personas, which people to group and on what. For recommendations, which events to recommend from. Name any Faraday capability the work depends on, such as Match Boost.
• Activation: what happens after Faraday delivers: what you or Faraday do with the results, any thresholds or buckets applied on top, and why any added data is used.

A real-time lookup needs only the identifiers each request sends and the fields each response returns, not a dataset or a population. A population of "everyone" is a complete answer, too.

If your agent writes use cases through the MCP server, it can call get_use_case_writing_guide for this same guidance, including the exact rubric the review applies.

Drafts and reviews

Mark a use case as a draft while it is incomplete. Drafts aren't reviewed.

When you save a use case that isn't a draft, Faraday reviews it within a few minutes. The review says whether the use case is adequate, meaning complete enough to build from, and lists what is missing or unclear. It also records where the work happens: in this account, or in sub-accounts it sets up for its own clients.

Fix what the review names and save again. The Dashboard's editor also shows a checklist while you type, so you can see gaps before you save.

Provisioning guides

If an adequate use case describes setting up the same thing for each of your clients, Faraday writes a provisioning guide for it: the steps to enroll a new client, with API requests checked against the API.

You don't write these guides yourself. To change one, edit the use case; a material change rewrites the guide. Provisioning guides are rolling out to accounts gradually.

Configuration audits

For a use case whose work happens in this account, Faraday compares your account's configuration with what your use cases describe, and reports:

• Changes: resources a use case needs that the account lacks, and resources configured differently from how the use case describes them.
• Orphaned resources: resources no use case asks for. These are advice only.
• Unmet prerequisites: things a use case needs that configuration can't provide, such as data you haven't sent yet.

An account is audited again whenever its configuration changes or a use case review finishes, and you can request one at any time. Applying an audit makes its changes for you, in the right order, and never archives or deletes anything.

Configuration audits are rolling out to accounts gradually. For now, Faraday applies audit changes on request. Ask your Faraday contact.