Skip to main content
The agent experience graph can explain more than a page view, but only if the evidence remains honest. Task intent evidence is an append-only, company-owned record of one agent-mediated customer task. It preserves what was stated or inferred, what the agent explored, what the product evaluated, and what the company observed afterward without turning sequence into attribution.

Evidence types stay separate

Each ledger is scoped to exactly one product-issued journeyId and uses four node types:
  • intent: a goal, requirement, preference, constraint, interest, or other task context;
  • journey: a question, path, option, disposition, or stage observed during the task;
  • decision: the company’s exact-match, near-miss, no-match, or unknown evaluation; and
  • outcome: a conversion, completion, or other stable company outcome label observed later.
An outcome is connected with an observed_after edge. The graph always carries attribution.status: "not_established"; there is no caused_by edge or causal score.

Provenance is required

Intent facts must declare one of three sources:
  • current_user_request;
  • user_confirmed; or
  • agent_inference_from_current_task.
Inference requires bounded confidence. It cannot overwrite direct user evidence. A changed value for the same dimension must explicitly supersede the prior fact, so contradictory values never disappear through last-write wins behavior. The ledger’s closed schema has no customer, account, cookie, prompt, or transcript field. Values are bounded, but the company must still pass only the minimum task-relevant value. Cross-session memory and personalization continue to use the separate permissioned customer-context flow. journeyId scopes and correlates navigation; it is never authorization. A production evidence reader must authenticate the company, resolve the journey inside that company’s product boundary, and reject cross-product or cross-tenant references before returning a snapshot. Raw prompts, personal data, payment details, and order details do not belong in the ledger.

Node SDK

Node IDs make identical retries idempotent. Reusing an ID for different evidence fails closed. Serialized snapshots can be validated and rehydrated; dangling, backward, cyclic, unknown-field, and false-attribution graphs are rejected.

Privacy-thresholded cohort analysis

Use @epode/node/intent-evidence/cohorts to describe how task evidence and separately observed outcomes co-occur across many validated ledgers. The analyzer publishes explicit eligible, observed, and missing task denominators. It never publishes journey IDs, intent values, option IDs, outcome labels, rankings, recommendations, or causal claims.
Analysis is deliberately limited to univariate intent-dimension, latest-decision-result, and terminal-status cohorts. Cohort labels and counts below the threshold are omitted. When either the observed or missing side of an outcome split is a non-zero small cell, both values are suppressed so the cohort total cannot reconstruct the protected cell. Intent-dimension cohorts can overlap; use each cohort’s task denominator and never sum cohort totals. The default threshold is 10 and cannot be lowered below 5. Threshold suppression reduces direct small-cell disclosure; it is not differential privacy, anonymization, or permission to publish customer data. Treat repeated, overlapping, or externally joined analyses as a new privacy review. Keep access tenant-bound, use stable analysis populations, and do not turn descriptive cohort differences into attribution or automated action. A difference is only a hypothesis for further measurement, never an effect estimate or action recommendation.

Browser-proven reference journey

Fieldnote preserves the original journey through negotiation, decision, item detail, and human handoff. Its purchase route records an accepted option followed by a separately observed conversion. The evidence endpoint requires an ephemeral server capability and returns the task snapshot and current summary, never the first-party browser cookie. The capability is a reference-product test seam; production uses normal tenant-bound company authorization. Run the real Chromium checks:
The first check uses isolated browser contexts for two realistic customers: one exact-match journey that crosses the agent-to-human handoff and purchases, and one hard-constraint no-match journey with no outcome. A second check runs 14 isolated agent tasks, completes five purchases in separate human browser contexts, and derives thresholded cohorts from the captured evidence. It verifies exact denominators, rare-label suppression, task isolation, and the fixed non-attribution disclosure.