AI use and HeldBy controls

What stands between an AI output and its effect.

Version 1.0 · Published 26 October 2026
Managed Functions Pty Ltd, trading as receipting.ai

Our HeldBy commitment

No AI output may leave the platform without a known HeldBy relationship. Each relationship identifies the AI process, what its output can reach, and the specific check or authorised person that holds it. The rule covers downstream uses, including broker messages and ledger postings, as well as the initial model response.

If the relationship is missing or its control is unverified, the output must not be released into that use. This is our control and release requirement; it is not a statement that every deployed path has already been independently verified.

The control follows what the output can do

We use AI to read documents, interpret names and records, support reconciliation, suggest mappings and answer product questions. The required control depends on the output's actual reach, including tools, permissions and later consumers. Where a process spans classes, the stricter class applies.

Read: check against the source

Extracted or interpreted information must be checked against authorised source facts, valid identifiers or recomputed totals. Unknown or invalid results must not become accepted facts. A separate human review is not required where those checks provide the necessary boundary.

Converse: keep the answer in a closed loop

A person starts the conversation, the answer stays with that person and receipting.ai, and it performs no consequential action or produces output that another process later acts on. The asker evaluates the answer; a second reviewer is not required for every response. If those conditions fail, the stricter Send boundary and any relevant Decide checks apply.

Decide: bound the action in code

Consequential actions such as matching or allocation require deterministic eligibility, scope, sign and amount checks and configured thresholds. Valid actions may proceed automatically. Missing, ambiguous, invalid or out-of-threshold results must go to a person or fail safely. Model confidence alone is not a release gate.

Send: a named person releases AI-written content

A named authorised person reviews and releases AI-written content carried to another recipient, with a record of who did so. This includes wording carried onward from an earlier process. Files and messages generated deterministically from records are not AI-written merely because AI helped develop the software.

Before every deployment

We must confirm that new or changed AI paths and their downstream uses are covered. This includes changes to prompts, models, providers, tools, permissions and consumers. We check the register against the code, verify the runtime controls and retain the evidence and known limits in the change record. An uncovered path must not ship.

Declarations, gateway-use checks, inventory scans and software review help find new or changed uses. They do not themselves stand between an individual AI output and its effect. A prompt instruction, gateway log, retry or another model's judgment is not a runtime hold on its own.

What this disclosure establishes

This document explains our existing HeldBy policy. It is not a complete inventory for every customer or deployment, an independent audit opinion, or a guarantee that AI results will always be correct. Enabled processes and controls depend on the service and configuration supplied to you.

Fleet-wide reconciliation of declarations, deployed callers and protected actions remains open. Historical scans and focused tests establish only their recorded scope and date. Unsupported languages, excluded paths, recorded pre-existing gateway bypasses and unverified downstream controls must remain visible as limitations or gaps; a passing declaration or lint check does not establish universal runtime coverage.

Data permissions remain separate

HeldBy does not authorise new access to your data or a new provider transfer. Customer, account and regional permissions, approved providers, and applicable training, retention, logging and transfer conditions must also be satisfied. A Read or Converse classification is not a data-residency or zero-retention assurance.

In-application processing uses regional AWS Bedrock inference; extraction and supporting pipelines also use the Anthropic API, which involves United States processing. The applicable configuration and contractual restrictions must be checked for your service. This document does not assert that all processing stays in your region or that every provider setting has been independently verified.

Your agreement and further information

This is an explanatory disclosure, not an addendum to the Terms and Conditions. It does not amend agreed service standards, liability, remedies or customer oversight obligations. Existing customer-specific notice, consent and approval requirements continue to apply; publishing an update here does not satisfy them by itself. Nothing here excludes rights that cannot lawfully be excluded.

Ask us for the AI uses, controls, verification dates and known limitations relevant to your service at legal@receipting.ai. Detailed evidence can be provided through an agreed review process.