Synapsor
Log inGet access
All docs
Docs
Getting Started

Value sources and lookup ids

Learn which example values you choose, which values your app sets in session, and which lookup ids or resource records Synapsor returns.

Overview

Synapsor examples use four kinds of values: schema names you define, trusted session values your backend sets, caller arguments supplied to a capability invocation, and lookup ids or resource records returned by Synapsor after the database records workflow state.

If a value appears inside quotes, it is not automatically user-defined. Strings such as 'acme' or 'support_agent_17' are app/session values; strings such as 'wrp://1', 'evidence://bundle/1', and 'agent-run://1' are Synapsor-produced lookup records that you copy from a response or query from system views.

Convenience aliases such as last_evidence and last_proposal are session/shell shortcuts for the most recently returned records. They are useful while learning, but production apps should store the durable proposal_handle, evidence_bundle, agent_run_id, run_resource, and branch_name returned by Synapsor.

A human does not need to browse all agent reads to find evidence. Start from the returned run/proposal/evidence id when your app stored it; otherwise search activity by project, database, tenant, principal, workflow, capability, business object id, query fingerprint, proposal/settlement id, request id, and time window.

Finding evidence when the lookup id is not in front of you

The returned id is the fastest path, but it is not the only path. User-facing app events should store Synapsor ids next to the business object they affected, such as ticket T-1042, invoice INV-3001, order O-778, or refund RF-19.

When a reviewer only knows the business object or approximate time, use the workspace Activity/Evidence/Proposal views or system views to narrow by tenant/principal, workflow, capability, object id, query fingerprint, proposal or settlement id, request id, and time window. From there, open the evidence bundle, query audit, proposal diff, approval/settlement record, branch state, and replay checkpoint.

Value provenance map

Read every Synapsor example by asking where each value enters the workflow.

You define
  • Table and column names: tickets, invoices, tenant_id
  • Context and capability names: support.ticket_context
  • Policy names: billing.green_late_fee_settle
  • Explicit branch names: invoice_3001_review
Your backend sets
  • SESSION tenant_id from authenticated account/project context
  • SESSION principal from the logged-in user or service identity
  • SESSION current_ticket_id/current_invoice_id from the selected object
  • SYNAPSOR_API_KEY from the dashboard API key screen
Caller supplies
  • ARG question from INVOKE ... WITH JSON or SDK arguments
  • ARG invoice_id, status, decision, note, or reason
  • Optional idempotency keys, trace ids, and request ids
  • auto_branch=true on HTTP/SDK proposal calls
Synapsor returns
  • agent_run_id and agent-run://... after capability invocation
  • evidence_bundle and evidence://... when evidence is recorded
  • proposal_handle such as wrp://1 after proposal creation
  • branch_name for explicit or auto-created proposal branches

Developer notes

  • Treat tenant, principal, entitlement, and current-object values as trusted backend session values, not prompt/user-editable text.
  • Treat ARG values as caller/model-visible inputs that still need validation through capability grammar, LOOKUP, TENANT, and policy rules.
  • Treat wrp://, evidence://, ctx://, and agent-run:// values as Synapsor-produced lookup records that can be inspected through READ RESOURCE or system views.
  • Use last_evidence and last_proposal only as learning/session aliases; persist durable returned ids in your app.