Overview
How publishing access, MCP-compatible calls, checks, fixes, and operational events support review and troubleshooting.
- Log publishing access.
- Log MCP tool calls.
- Keep evidence and retest history.
- Use logs to explain changes.
How this works in Akii
How publishing access, MCP-compatible calls, checks, fixes, and operational events support review and troubleshooting. 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.
- Log publishing access.
- Log MCP tool calls.
- Keep evidence and retest history.
- Use logs to explain changes.
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.