Customer data handling

Customer teams usually want a simple answer here: your Ledgix configuration, policy content, review settings, and audit history are scoped to your tenant. Other customers do not share those settings or request records.

What stays tenant-scoped

Field	Type	Required	Description
API keys	Tenant credential	Yes	Keys created in your dashboard authorize only your tenant's requests.
Policy content	Tenant content	Yes	Uploaded files, pasted text, structured rules, and imported Confluence pages apply only to your tenant.
Review settings	Tenant configuration	Yes	Minimum confidence score and notification settings are stored inside your tenant's own Ledgix data boundary.
Review queue	Tenant workflow	Yes	Pending review items are stored and shown per tenant, not in a shared customer queue.
Ledger and proofs	Tenant evidence	Yes	Request history and verification artifacts are retrieved with your tenant credentials.

What this means for your team

Upload policy content that matches your own operating rules, not generic examples.
Create separate API keys for the environments and services you want to distinguish.
Expect reviews, thresholds, and notifications to reflect your tenant's decisions, not shared defaults for everyone.
Treat request_id and audit artifacts as customer records tied to your tenant's own activity.

What Ledgix uses your data for

Ledgix uses the data you provide to:

evaluate whether a request should be approved, denied, or reviewed
show reviewers the request details, reasoning, and citations they need
return audit and verification data for your own past requests

This is why policy quality matters. If the uploaded policy does not reflect the real rule, the decision quality will not reflect the real rule either.

What you should send

Only send the data Ledgix needs to evaluate the action. Good request payloads are:

specific enough to decide the policy question
stable enough to log and review later
limited to the fields required for the protected action

If your request payload contains unnecessary sensitive detail, Ledgix cannot remove that risk for you. Customer-side payload design still matters.

Shared responsibilities

Ledgix handles the decision and evidence flow. Your team is still responsible for:

storing API keys safely in your own environment
deciding who can review pending actions
keeping policy documents current when your rules change
choosing the correct tool boundary so the real side effect is what gets approved

Questions this page answers

"Will another customer see my policy documents?" No.
"Does another tenant's threshold affect my requests?" No.
"Do my reviewers act on another tenant's requests?" No.
"Do I still need to think about which fields I send?" Yes.