What Veefore is not
The deliberate exclusions, why each one is excluded, and the build gate that keeps them out.
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:
- A policy input. A rule tests it. A delegation caps it. A risk signal compares it against history.
- 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_balanceorfundsexists in any migration. - Any table with an
amountcolumn 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 ownplans,subscriptionsandusage_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.