Data requirements
A smaller, documented input makes the service safer and easier to audit.
The normal starting point is a pseudonymized supplier-metric CSV. Nothing operational should be sent through the public website.
Accepted profile
Fields the working schema is designed around.
- supplier token
- metric code
- period index
- target band
- observed band
- dispute state
- data status
- buyer note code
The field list is a planning profile, not a request to email data. The exact schema and secure exchange are agreed in writing after fit review.
Explicit exclusions
Data and authority we do not need.
No supplier sanctions, autonomous sourcing decisions, ERP writes, performance guarantees, or unsupported benchmark claims.
Credentials, unrestricted system access, and unrequested free text are never part of the published plan.
Data lifecycle
Five visible handling stages.
- 01
Agree
Write down the permitted fields, purpose, owner, transfer, retention, and deletion rule.
- 02
Prepare
The buyer exports and normalizes only the agreed minimum input.
- 03
Validate
Schema failures and unknown values are rejected without inference.
- 04
Deliver
Portable outputs carry definitions, exceptions, and confirmation states.
- 05
Delete
Working data follows the written retention rule; the buyer keeps the final pack.
Field glossary
Shared definitions prevent expensive rework.
- Metric definition
- The exact numerator, denominator, scope, and period agreed by the buyer.
- Target band
- A buyer-set range used for discussion, not an external benchmark.
- Dispute state
- Whether an observation is accepted, questioned, or unresolved.
- Reporting unit
- The buyer-defined business, site, or category view.
- Data status
- Complete, missing, rejected, or not applicable.
- QBR brief
- A concise discussion pack; not an autonomous supplier decision.
A useful first conversation
Check the data boundary before discussing a plan.
Describe it in general terms. We will tell you which plan fits, what we would need, and where we would draw the line.