> For the complete documentation index, see [llms.txt](https://docs.cortex.aic.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cortex.aic.io/workflow-guides/analyse/synapse.md).
# Synapse
**Open this area:** In the CORTEX menu, select **Sources & evidence → Graph explorer**.
Build explicit entity records and evidence-backed relationship claims while retaining contradictions and exact revision decisions.
**Who uses this:** Analyst, Reviewer\
**Open in CORTEX:** `/synapse/graph`\
**In-app guide:** `/help?topic=synapse`
**Expected result:** An entity or relationship has inspectable evidence, clear review state, and retained correction history.
## Before you start
* Have Synapse and Memory enabled with current read and relevant write/review authority.
* At least one Ready material record with a retained extraction and exact quotation is required before creating a cited entity. The editor checks what is visible in the current workspace and links to Memory when none is available.
* Prepare handling that covers every cited passage and relationship endpoint. Check existing entities; similar names or aliases do not automatically establish identity.
## What to do
{% stepper %}
{% step %}
## Find or create the entity
Use **Find entities** to check names and aliases.
The list pager appears only beyond one page and shows the exact visible range; unsent filter edits do not change paging until **Find entities** is selected.
If a separate record is justified, choose **Create cited entity**.
* The **Details** step needs a name, kind, and description.
* **Evidence** needs at least one exact quotation from Ready material.
* **Review** saves once.
Recheck Ready evidence after preparing material elsewhere.
Coloured step states show what still needs attention. Leaving an edited entity draft asks before discarding unsaved entries.
{% endstep %}
{% step %}
## State the relationship claim
From an active entity choose **Draft a relationship**, or use the relationship list.
One prerequisite panel shows:
* Relationship access
* Two distinct active cited entities
* Ready evidence
Recheck Ready evidence after preparing material elsewhere; create another cited entity if an endpoint is missing.
Select the endpoints, then enter:
* A 3–120 character label
* A 10–2,000 character claim
An optional identity proposal adds four required pilot and scope descriptions and needs endpoints of the same kind.
Required labels and colored step states show what remains.
{% endstep %}
{% step %}
## Retain supporting and contrary material
The **Evidence** step needs 1–8 exact citations, each marked **Corroborates** or **Contradicts** with 10–1,000 characters of relevance and limitations.
Review and save retains one draft; moving between steps does not save.
Correcting a decided relationship:
* Needs a 10–500 character reason
* Creates a new Draft revision
* Removes current acceptance while retaining its history
An edge is still a claim, not proof of association.
{% endstep %}
{% step %}
## Propose and decide the revision
On the relationship detail, give a reason and select **Propose relationship revision**.
An authorised reviewer then records **Accept** or **Reject** with **Record relationship decision**.
Acceptance needs a corroborating citation and retains contradictions.
{% endstep %}
{% step %}
## Inspect and arrange the bounded graph
Open **Graph explorer** from the workspace collaboration rail or Synapse navigation.
It needs at least one visible active cited entity and links to entity creation when none is available.
Choose an entity, drag nodes or use arrow keys to arrange them, and follow directed relationship lines.
Changes remain local to this browser until **Save team layout** is selected.
Team save uses version checks and current graph access; the textual table remains the authoritative route to the relationship revision.
{% endstep %}
{% step %}
## Correct after a decision
Use the entity graph and its textual table to inspect accepted one-hop links and any **HasMore** indication.
Correct a relationship after a decision to create a new Draft; review the changed claim again rather than relying on its earlier acceptance.
{% endstep %}
{% endstepper %}
## Check the result
* Have I avoided conflating similar names?
* Does each claim have exact, relevant citations?
* Have contradictions and alternative interpretations stayed visible?
* Does the review apply to this content revision?
* Am I interpreting the graph as a bounded view rather than a complete network?
## If you get stuck
How do I keep a useful graph arrangement?
Drag a node or focus it and use arrow keys.
Local positions stay in this browser and take precedence until you select **Save team layout**.
A team save records the actor, UTC time, version and current authorised positions for the selected focus. If someone saved another version first, refresh and retry deliberately.
A partial graph view cannot save or reset team positions because that could erase positions you cannot see.
If access changes after a conditional write, reload because the save may have occurred.
Use **Reset local arrangement** to return to the team layout, or **Reset team layout** to retain the layout record with default positions.
Neither reset changes entities or relationships.
Why is a relationship missing from the graph?
The graph shows only currently visible Accepted one-hop relationships within the selected limit.
Check its state, endpoint eligibility and **HasMore**; use the relationship list to inspect other authorised claims.
Why can I not correct a Proposed relationship?
The proposed revision must receive a decision first.
Have an authorised reviewer decide it, then create a reasoned correction; prior content and decisions remain retained.
Why did an evidence save fail after reprocessing?
A new correction re-resolves citations and requires Ready material.
Refresh the material's stored state and retry deliberately when Ready; existing history remains pinned to its earlier extraction.
## Responsibility and limits
* Analysts substantiate identity and relationships; aliases, graph proximity and an accepted state do not certify reality.
* Ordinary relationship claims permit author review. Typed identity-resolution proposals require a different authorised reviewer; neither decision is product release approval.
* Local and team arrangements contain bounded node coordinates only. They do not store labels, evidence or hidden graph membership, and do not replace governed entity, relationship or analysis records.
**Reference and scope:** Implementation guidance supporting collation, evaluation and analysis in JDP 2-00 (4th ed.), 3.35–3.48. A graph layout is not a doctrinal assessment or an inference engine.
## Related workflows
* [Review identity and reporting independence](broken://pages/8a49e5dfc2cd188078d2545b17a4880e8122acbf)
* [Find evidence and select exact retained passages](broken://pages/e6eab51e146c4db1e002b720557a5faea932e41c)
* [Develop and independently review an assessment](broken://pages/79db57a6c6245feef3fb58e4fe6d4a507b2a74a0)
* [Author an intelligence Product and inspect its exports](file:///7397340/product/products.md)