> For the complete documentation index, see [llms.txt](https://docs.origintrail.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.origintrail.io/for-agents/publish-query.md).

# Publish & Query

**Inputs:** exact graph, authorized caller, task, intended memory layer, and any existing KA/job identifiers. Discover tool schemas first: MCP/HTTP commonly use `contextGraphId`; Hermes/OpenClaw expose fields such as `context_graph_id`. Do not infer compatibility from a similar tool name.

## Retrieve evidence

1. Check caller identity and the exact graph. Use memory search for recall, or inspect vocabulary and use SPARQL for a structured question.
2. Select the intended view: `working-memory`, `shared-working-memory`, or `verifiable-memory`. Use named graph patterns when data is routed into named graphs.
3. Inspect returned rows and source identifiers. If empty, check scope, permission, layer, and sync before concluding that no evidence exists.
4. Report the answer with its source, layer, and available version/commitment. Re-read when freshness matters.

## Write and share

1. Create/select a named WM KA in the authorized graph.
2. Write source-backed RDF. Inspect the returned quads before progressing.
3. Seal the draft. This is an author attestation, not an on-chain transaction.
4. Share when the task authorizes peer visibility. A full share can seal automatically; use the installed contract and keep a single explicit lifecycle in the task.
5. Inspect completion and any nested errors. A `207` or retryable failure does not permit silently moving on to publication. Resume the existing named operation under its recovery contract.

The [quickstart](/start-here/quickstart.md) gives exact CLI commands and a five-triple fixture. The [HTTP example](/build-with-dkg/http-application.md) shows request bodies and result handling.

## Publish intentionally

1. Establish authorization for funded publication, the intended network, author, and payer. Reuse authorization already given for this task; ask only if the transition is not authorized.
2. Confirm the selected KA is fully shared and sealed, and that funds/required publishing permissions exist. Check PCA ownership/agent registration before assuming its funding path applies.
3. Use the named KA's supported VM publish route/tool. For async publication, confirm publisher setup and save the job ID.
4. Inspect the returned transaction, chain finality, local reconciliation, and lifecycle. Acceptance, a transaction hash, and completed publication are distinct states.
5. Read back the intended VM content/version. Report the UAL, source, and actual verification evidence. Publication proves neither factual truth nor independent corroboration.

**Recover:** preserve KA/job identity. Follow [publisher recovery](/operate/async-publisher-wallets.md) for ambiguous chain outcomes; never publish a replacement name merely to bypass a held job. Follow the [edit lifecycle](/operate/knowledge-asset-lifecycle.md) for an intended update.

**Done:** the requested operation has observable completion, and the answer identifies the actual layer. If only WM was requested, stop there.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.origintrail.io/for-agents/publish-query.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.