Skip to main content

Context Fabric Lifecycle

Context Fabric turns scoped engineering and agent context into governed, searchable records. Its lifecycle is:

  1. configure an agent;
  2. register an exact working scope;
  3. capture or share context;
  4. search and resolve relevant context;
  5. verify, correct, flag, or resolve conflicts;
  6. measure and reuse trusted work;
  7. flush completed session context; and
  8. purge user context when required.

Context is not globally interchangeable. Organization, user, team, agent, repository, branch, session, and provenance boundaries determine what can be stored and recalled.

Configure the agent​

The current gateway response-capture path actively applies these declarative agent settings:

  • enabled;
  • capture_mode; and
  • capture_exclude_patterns.

The configuration schema also accepts and resolves pool limits, TTLs, deduplication and compaction thresholds, PII/DLP flags, confidence and verification settings, branch inheritance, cache settings, conflict strategy, multi-gateway settings, and direct_answer_threshold. Those additional values do not currently change the gateway response-capture or customer search behavior. In particular, customer search currently uses a fixed 0.85 direct-answer threshold.

Do not rely on an accepted setting as an enforced retention, privacy, or search control. Verify the active behavior described here and enforce required retention and data-classification rules through supported controls before enabling capture. Set active values through the agent's owned configuration or control manifest.

Register a working scope​

POST /v1/context/register registers or updates the authenticated user's session with:

  • session_id;
  • repository;
  • branch;
  • optional commit;
  • optional working directory; and
  • optional team scope.

Register again when the repo or branch changes. A branch change creates a new History session relationship rather than silently treating the work as the same branch scope.

Do not use a repository name alone as a security boundary. Authentication, organization membership, team scope, and API authorization remain required.

Capture and share context​

Capture behavior depends on the agent's mode. Manual sharing uses POST /v1/context/share and can include session, team, repo, branch, commit, source, tags, verification, and provenance context.

When branch scope is provided, repository scope is required. Duplicate detection can return a resolution choice such as replace, keep both, or discard. Review the duplicate content and scope instead of automatically replacing it.

Before sharing:

  • remove secrets and unnecessary personal data;
  • confirm the target team and repository;
  • attach useful provenance;
  • classify whether the content is observed, inferred, or verified; and
  • use an exclusion pattern for paths that must never be captured.

PII/DLP controls add protection but do not authorize collecting content that the organization prohibits.

Search and inspect​

EndpointPurpose
POST /v1/context/searchSearch within authorized team, agent, repo, branch, and session scope
GET /v1/context/recentList recent context for a bounded scope
GET /v1/context/schema/{table}Retrieve context about a named schema/table
POST /v1/context/graph/queryQuery governed context graph relationships
GET /v1/context/graph/entity/{name}Inspect one graph entity
POST /v1/context-resolution/inspectInspect a staged resolution plan and trace
GET /v1/context/statsRead agent/range/branch statistics

Search requires a query unless the request uses the supported agent-scoped listing mode. Disputed content is excluded by default unless an authorized caller explicitly asks to include it.

Direct answers are suggestions backed by returned source document IDs and confidence. Preserve those sources and do not present the answer as verified when its source is not verified.

Resolution inspection redacts content unless the caller both asks to include it and is allowed to view every included item.

Build the context graph​

Use POST /v1/context/graph/upsert only for authorized, sourced graph facts. Query the graph before adding a duplicate entity and retain the source reference used to justify each relationship.

Graph presence does not make a fact current. Pair graph results with provenance, confidence, verification status, and timestamps.

Verify and improve context​

Context can receive:

  • verification outcomes;
  • helpful or not-helpful feedback;
  • corrected content;
  • verified, disputed, or flagged votes; and
  • conflict resolutions.

Use:

  • POST /v1/context/verification/apply for bounded verification outcomes;
  • POST /v1/context/feedback for helpfulness or corrections;
  • POST /v1/context/flag for flag, verify, or dispute actions;
  • GET /v1/context/conflicts to list conflicts; and
  • POST /v1/context/conflicts/resolve to resolve one.

An out-of-scope document is skipped rather than updated by verification apply. Inspect the response counts and per-document outcomes.

Corrections should add the evidence and scope that make the new content reviewable. Do not erase a disagreement merely to improve a confidence metric.

Work receipts and reuse​

POST /v1/work-receipts captures reusable evidence about completed work, and POST /v1/work-receipts/search finds scoped matches. The gateway re-evaluates current governance before using a receipt.

Current execution behavior, trust states, poisoning defenses, and verifier limits are documented in Context Fabric Work Reuse.

Treat avoided work and cost as operational estimates, not invoice truth.

Flush completed context​

POST /v1/context-flush condenses eligible session context into a reusable recall document. The request is tied to a History session and context-plan hash; repeating the same completed flush returns the existing result.

Flush only after the session's source material and scope are correct. Verify:

  • session ID;
  • context plan and hash;
  • generated recall document;
  • retention and verification state; and
  • resulting search behavior.

Flush is not an organization-wide deletion operation.

Purge a user's context​

DELETE /v1/context/by-user/{id} is the destructive privacy lifecycle for context associated with a user. It can affect registrations, feedback, and stored context relationships.

Use it only through an approved privacy or offboarding workflow:

  1. Verify the subject ID and organization.
  2. Identify legal hold and retention constraints.
  3. Obtain required approval.
  4. Capture the pre-operation scope without copying unnecessary content.
  5. Execute once.
  6. Record the response counts.
  7. Verify the user no longer appears in authorized context searches.
  8. Preserve Trail evidence of the operation.

Do not substitute a context flush for a user purge or assume membership removal performs the purge automatically.

Customer and machine API boundaries​

This page lists the bearer-authenticated customer routes under /v1/context, /v1/work-receipts, /v1/context-flush, and /v1/context-resolution/inspect.

Routes under /v1/gateway/... are machine-authenticated runtime surfaces. Customer applications should not call those routes with a human or ordinary API token.

Next steps​