Decisions as infrastructure.

Status

Where each surface stands

• Web workspace

  Available now

  Submit company domains, get a verdict with its evidence for each one, define your targeting policy and request more research on accounts held at RESEARCH_MORE. Free for your first 10 accounts.

  Implemented

  Yes

  Deployed code

  Yes

  Enabled in production

  Yes

  Publicly available

  Yes

• API

  Implemented · not yet enabled

  Request a decision on an account and read its Decision Record from your own code, with a workspace API key. Public production access is not yet enabled.

  Implemented

  Yes

  Deployed code

  Yes, switched off

  Enabled in production

  No

  Publicly available

  No

• MCP

  Implemented · not yet enabled

  The same decisions as tools for AI agents and assistants, through the Model Context Protocol, as a remote endpoint or a local server. Public production access is not yet enabled.

  Implemented

  Yes

  Deployed code

  Yes, switched off

  Enabled in production

  No

  Publicly available

  No

• CLI

  Implemented · not yet enabled

  Request and read decisions from a terminal or a pipeline. The CLI is a client of the API: it is not yet published, and it works only once API access is enabled.

  Implemented

  Yes

  Deployed code

  No, not published

  Enabled in production

  No

  Publicly available

  No

• HubSpot decision loop

  Built · not yet active

  A company event triggers a decision; after human approval, four OutboundFix fields are written back to the company record. Built and tested end to end. Not active for any customer yet.

  Implemented

  Yes

  Deployed code

  Webhook endpoint only, not configured

  Enabled in production

  No

  Publicly available

  No

• Clay account intake

  Built · not yet active

  A Clay table sends enriched accounts to OutboundFix for a decision. Clay data is kept as context and never decides on its own: the verdict comes from OutboundFix Core. Built and tested. Not active for any customer yet.

  Implemented

  Yes

  Deployed code

  Intake endpoint only, not configured

  Enabled in production

  No

  Publicly available

  No

Implemented means built and covered by tests in the repository. Deployed code is what of it ships in the production service: switched off or not configured, it refuses every request. Nothing on this page is a published contract, and there is no public endpoint, API key or package to install yet.

Architecture

One governed decision boundary

The API, the MCP server and the CLI are three adapters over one access pipeline and one governed boundary onto OutboundFix Core V2. The same request produces the same decision and the same Decision Record whichever surface carries it, and no surface computes a verdict of its own. The Clay and HubSpot integrations arrive through their own intake and are decided by the same Core V2 engine.

An integration or a provider can add evidence and context to a decision. It cannot supply the verdict, override your policy or widen what OutboundFix may do. Core owns the judgment.

Decisions in the web workspace today come from the earlier targeting runtime: the same three verdicts under your policy, recorded without the Core V2 argument and fingerprint.

The object you integrate

What a Core V2 decision carries

• Engine outboundfix-core@targeting-v2, record schema outboundfix-decision-record@2.
• A decision argument: the reasons that support the verdict, the counter-arguments, the decisive evidence, and how each policy criterion and disqualifier was resolved.
• Typed uncertainty: each open question is classed as missing evidence, conflicting evidence, source reliability, staleness or policy ambiguity, and marked as blocking the verdict or not.
• A decision fingerprint: a SHA-256 over the engine and rule versions, the policy, the evidence and the evaluation time. The same inputs give the same fingerprint.
• By default, PASS needs every required criterion confirmed and every disqualifier resolved as not applying: a disqualifier nobody could resolve holds the account at RESEARCH_MORE.

A response carries the verdict, the engine and record versions and the fingerprint. Reading the record adds its evidence, what is missing, the open uncertainty as text and the research objectives. The decision argument itself is stored with the record and is not returned yet.

{
  "domain": "solandra.example",
  "verdict": "PASS",
  "decisionRecordId": "5d1c0e7a-9b42-4c1e-8f6a-2e1b7c94a41f",
  "supersedesDecisionRecordId": null,
  "decisionStatement": "PASS: POSITIVE_QUALIFICATION_SATISFIED",
  "engineVersion": "outboundfix-core@targeting-v2",
  "decisionSchemaVersion": "outboundfix-decision-record@2",
  "decisionFingerprint": "2774865c09a2132c1c7b8ca0bd44561cc4374826243991f70eb8db94443f4417",
  "policy": {
    "source": "CUSTOMER_ACTIVE",
    "version": "4"
  },
  "providerUsage": [
    {
      "provider": "google-gemini",
      "billedTo": "CUSTOMER_PROVIDER_ACCOUNT",
      "modelCalls": 1,
      "outcome": "SUCCEEDED"
    }
  ]
}

Abridged and illustrative, for a fictional account. The field names and the engine and schema values are the ones the implemented API returns; until public access is enabled they are not a published contract.

What stays true on every surface

Properties of every decision

• Three verdicts only: PASS, RESEARCH_MORE, KILL. A verdict is a decision under your policy, never a threshold on a score.
• The verdict is issued by a deterministic runtime. AI gathers evidence and never decides.
• A record is immutable. More research or a re-evaluation writes a new record that supersedes the old one and points to it.
• Every record names its policy version and carries its reason codes.
• When research fails or a claim cannot be verified against its source page, no PASS or KILL is produced.

One registry, three surfaces

What the API, MCP server and CLI do

• Capability discovery
• Workspace usage
• Evaluate an account
• Re-evaluate an account with the active policy
• Get a decision record
• List decisions
• List provider credentials
• Set or rotate a provider credential
• Revoke a provider credential

The MCP server offers the same operations as tools, except setting or revoking a provider credential: a provider secret is never an MCP argument. An evaluation uses one unit of the workspace’s allowance. Re-evaluation applies only to an account’s current RESEARCH_MORE decision and uses none.

Provider credentials

Your model provider, your bill

• Evidence extraction is a metered call to a third-party model provider. Through the API, the MCP server and the CLI, and for research on a decision Clay triggered, it runs on your workspace's own provider credential, and the provider bills you directly.
• OutboundFix does not fall back to a key of its own. Without your credential, an evaluation through the API is refused before anything is spent, and research on a Clay-triggered decision does not run.
• One evaluation through the API makes at most one call to the provider, and OutboundFix does not retry it.
• A stored credential is encrypted, bound to your workspace and never returned.
• The web workspace does not ask for a provider key.

Bring-your-own-key support today: Google Gemini. No other provider is supported yet.

Governed authority

Decisions, not actions

• The API, the MCP server and the CLI request and read decisions. None of them can approve, execute, activate a policy, grant authority or write to a CRM, and an API key is not an approver.
• Running an evaluation needs more than a key: OutboundFix provisions each workspace for evaluations. Until then, an API key can read decisions and manage the workspace's provider credential, and nothing else.
• Acting on a decision stays behind explicit authority and human approval, in the governed HubSpot loop described below.

Integrations

HubSpot and Clay

HubSpot decision loop

Built and tested end to end. Not active for any customer yet. A company created or changed in HubSpot triggers a decision. After a named reviewer approves it, OutboundFix writes exactly four company properties and nothing else:

• outboundfix_decision
• outboundfix_decision_record_id
• outboundfix_policy_version
• outboundfix_reason_codes

Autonomous write-back is not enabled.

Clay account intake

Built and tested. Not active for any customer yet. A Clay table sends one enriched account at a time. What Clay sends is kept as context in the evidence graph, so Clay data alone never produces a PASS or a KILL: anything beyond RESEARCH_MORE comes from OutboundFix Core’s own research of the account’s official website, on your provider credential. A Clay connection holds no authority to act on a decision. See integrations for where OutboundFix sits in your stack.

Get access

Start in the workspace

Public production access to the API, the MCP server and the CLI is not yet enabled, and there is no self-serve API key. The workspace is where decisions run today, so the fastest way to evaluate OutboundFix is to put your own accounts through it. If you need programmatic access, tell us what you are building.