Overview
Reference docs for entities, schemas, action types, protocol statuses, issues, readiness, plan limits, FAQ, and changelog.
- Use reference docs for exact terms.
- Implementation docs explain workflows.
- Protocol pages explain external standards.
How this works in Akii
Reference docs for entities, schemas, action types, protocol statuses, issues, readiness, plan limits, FAQ, and changelog. This page should be read as an operating reference, not a marketing claim: it explains which data, checks, outputs, or workflow steps need to be reviewed before a client brand treats the result as ready for public or partner use.
- Use reference docs for exact terms.
- Implementation docs explain workflows.
- Protocol pages explain external standards.
Implementation workflow
Start with the client brand and the current approved Commerce Graph. Confirm the relevant sources, offers, policies, locations, action paths, publishing settings, and protocol status before publishing, reporting, or handing work to a client, partner, or developer.
- Confirm the client brand and graph version.
- Review source evidence and approval state.
- Check publishing, export, report, or action-path settings tied to this workflow.
- Record issues or missing fields in Fix Queue when the workflow is not ready.
Evidence to review
Use Akii evidence rather than assumptions. A useful review includes the approved source list, the fields that changed since the previous graph version, the latest Answer QA result, any protocol readiness gaps, and the owner responsible for unresolved fixes.
Operational boundary
Akii keeps approved client data, public output, private data, partner exports, and protocol claims separate. If a capability requires configuration, partner access, or external platform support, the docs say so explicitly. Readiness, export, support, and planned statuses should not be collapsed into certification or external platform approval.
What to check before publishing
Before treating the workflow as production-ready, confirm source proof, approval state, output health, action-path tests, public/private field boundaries, and any relevant protocol readiness checks. If the page supports a client or partner handoff, include the safe claim, limitation, and next fix so the recipient understands exactly what Akii has verified.