Answer a question from June's shared knowledge graph — grounded in stored evidence, with citations, and it abstains rather than guessing when the graph doesn't know. Use when you want a finished answer to a factual question about remembered knowledge (people, projects, documents, decisions); use june_context instead when you want raw material to reason over yourself, and june_search when you only need ranked matching items. May take longer than other tools (it runs one LLM synthesis). Returns {answer, citations, used_edge_ids, degraded, mode}; an empty answer or 'abstain' in degraded means the graph has no grounded answer.

Fused retrieval over the knowledge graph: lexical + dense + graph signals in one ranked list. Use when you need matching items (nodes/snippets with scores and provenance) — e.g. to find entities or check what the graph holds on a topic; use june_answer for a finished cited answer, june_context for a prompt-ready pack. Returns {items[], degraded_lanes, …}.

Exhaustive structured retrieval: return EVERY node matching a predicate (terms / regex / node_types / subtype) — not a top-k slice. Use for aggregation questions like 'list ALL customers/incidents/…' where june_search's ranked window could miss members; then reason over the complete list. Returns all matches up to cap (default 500).

One call → a ready-to-use context pack: ranked evidence folded to canonical entities (aliases merged), trimmed to a token budget. Use when you want June's knowledge as raw material inside YOUR reasoning or a long draft; use june_answer when you want June to produce the answer itself. Returns {items[], budget, …} sized to token_budget.

The 1-hop edges around one node — who/what connects directly to it. Use after june_search gave you a node_id and you want its immediate relations; use june_subgraph for multi-hop expansion. Requires node_id + node_type from a prior result. Returns {edges[], …}.

Depth-N neighbourhood around a node (multi-hop expansion, bounded). Use to map a cluster of related entities around a known node; use june_neighborhood for just the direct edges. Requires node_id + node_type from a prior result. Returns {nodes[], edges[], …}; depth ≤ 3.

Save new information into the shared graph by writing text: June extracts entities and relations server-side and links them to what it already knows (on Pro endpoints the richer entity/edge engines run automatically; the result reports which engine ran). Use when the user states a fact, decision, update or note worth persisting for later ('remember that…', meeting notes, a status change). Plain text or markdown, up to ~64k chars. Returns write counts — cite them, don't echo the text back. Prefer this over june_ingest unless you must write explicit graph structure.

Advanced write: push explicit graph structure (node rows + edge proposals) exactly as given. Use ONLY when you already have structured nodes/edges with ids and kinds — for ordinary 'remember this' information, june_remember is the right verb (it extracts structure for you). Returns write counts.

Pro: re-extract THIS canvas's existing artifacts with the richer engine, as a background job (idempotent — a second run writes 0 new). Use after a Pro upgrade to backfill memories that were written on the free floor, or after many june_remember writes. Call with no args to start (returns job_id; 409 if one is already running; 403 on free endpoints), then call again with {job: } to check progress. Returns {job_id, state, total, processed, nodes, edges, errors}.

Maintenance: run cross-format entity resolution over the canvas — merges duplicate entities via reversible same_as edges (runs server-side, server-bounded scan). Default strong_only=true is conservative (deterministic signals only); pass strong_only=false to also use the fuzzy tier — which upgrades to SEMANTIC matching on Pro endpoints. Use once after a batch of june_remember/june_ingest writes, not per question; reads are already resolution-aware. Returns {same_as_written, groups, candidates}.