---
title: What Veefore is not
description: The deliberate exclusions, why each one is excluded, and the build gate that keeps them out.
label: Scope
---

A product is defined as much by what it refuses to do. Veefore is identity,
authority, policy and enforcement infrastructure. Several adjacent things it is
frequently assumed to be, it is not — and those are not gaps waiting to be
filled. They are design decisions with a build gate behind them.

## The exclusions

| Not in Veefore | Why |
| --- | --- |
| Wallet | Holding a balance means custody of funds. Veefore stores no balances; the schema has no balance column, and the audit refuses one. |
| Marketplace | There is a **private registry** for finding your own organization's agents. A public marketplace with listings, prices, sellers and reviews is a different product. |
| Agent commerce | Agent-to-agent trade is excluded from the starting product. A2A exists for *invocation* under policy, not for transacting. |
| Payment processing | Veefore never authorises, captures or voids a payment. No processor integration, no card data, no payment intents. |
| Settlement, payouts, disbursement | All money movement. |
| Financial transaction ledger | A double-entry ledger is financial infrastructure. Veefore records *decisions*, not balances. |
| Contracts and smart contracts | Contract lifecycle management and on-chain execution are both different product categories. Nothing here touches a blockchain. |
| Merchant acquiring | Payment infrastructure. |
| Agent purchasing | An agent may be authorised to call *your* purchasing tool. Veefore implements no cart, no checkout and no order flow. |
| Marketplace reviews and ratings | Follows from having no marketplace. |

The same list is served at `GET /v1/meta/info` under `out_of_scope`, without
authentication, so an integrator can check it against the deployment they are
actually talking to rather than against a document.

## Then why is there an `amount` field?

Because a policy needs to be able to say *"refunds above ₹1,000 need a human"*,
and that sentence requires a number.

`amount` is in minor currency units, and it appears in exactly two roles:

1. **A policy input.** A rule tests it. A delegation caps it. A risk signal
   compares it against history.
2. **Recorded decision context.** The action record keeps what the agent asked
   to do, so the decision is explainable later.

It is never a balance, a transfer, a charge or a settlement instruction. Veefore
reads the number, decides, writes down what it decided, and moves nothing.

The money that actually moves moves in *your* system, called through *your*
tool, with a credential Veefore brokered after permitting the action. Veefore is
the thing that decided it was allowed to happen. It is not the thing that
happened.

## This is enforced, not just documented

`npm run scope:audit` fails the build if any excluded concept appears as an
implementation. It is part of `npm run verify`, so it runs on every change.

It checks two different things, because keyword matching alone is easy to evade:

**Naming.** Table names, service class names, route paths, identifiers and
navigation labels. A `WalletService`, a `/v1/payments` route, a `CREATE TABLE
settlements`, a `seller_id` column, a `checkout_session` — each is a failure.

Comments and prose that *state* the boundary are allowed, which is why this page
can exist. A negated mention ("this is not a marketplace") is documentation, not
an implementation.

**Shape.** A wallet could be written without the word "wallet", but it would
still need a balance column. So the audit also asserts:

- No column named `balance`, `available_balance`, `ledger_balance` or `funds` exists in any migration.
- Any table with an `amount` column must be on an explicit allow-list of policy and decision tables — `actions`, `approvals`, `delegations`, `delegation_constraints`, `policy_versions`, `policy_test_cases`, `risk_events`, plus Veefore's own `plans`, `subscriptions` and `usage_records`.

An amount column appearing on a table that is not a policy or decision table
fails the build with that table named. That is the check that makes the
exclusion structural rather than aspirational.

## What it does mean for you

If you are building something that needs any of the above, build it as **your
system** and register it as a tool. That is the intended shape:

- Your refund service is a tool. Veefore decides whether the agent may call it.
- Your ledger is yours. Veefore records the decision that preceded the entry.
- Your payment provider is yours. Veefore brokers the credential and holds the agent to a ceiling.

The division of labour is the point. Veefore is good at deciding and proving. It
has no business holding your money.

## Related

:::cards

:::card Scope boundaries, in full | /architecture/adr/0001-scope-boundaries
The decision record, with the alternatives that were considered.
:::

:::card Register a tool | /build/register-a-tool
How your system becomes something an agent can be authorized for.
:::

:::card Policy fields | /reference/policy-fields
Every field a rule can test, including how `amount` is typed.
:::

:::