Context Fabric Lifecycle

Context Fabric changes scoped engineering and agent context into governed, searchable records. Its lifecycle has these stages:

1. Agent configuration sets the capture behavior.
2. Scope registration sets the selected work boundaries.
3. Capture or manual sharing adds context.
4. Search and resolution find related context.
5. Verification and feedback correct context.
6. Work receipts support trusted reuse.
7. A flush closes completed session context.
8. A purge removes user context when necessary.

Context stays in its authorized scope. Organization, user, team, agent, repository, branch, session, and provenance boundaries control storage and recall.

Configure the agent

During response capture, the gateway applies these declarative agent settings:

• enabled.
• capture_mode.
• capture_exclude_patterns.

The configuration schema also accepts and resolves these settings:

• They include pool limits and TTLs.
• They include deduplication and compaction thresholds.
• They include PII and DLP controls.
• They include confidence and verification settings.
• They include branch inheritance settings.
• They include cache settings.
• They include a conflict strategy.
• They include settings for multiple gateways.
• They include direct_answer_threshold.

These settings do not change the active gateway capture or customer search behavior.

At this time, customer search uses a direct answer threshold of 0.85.

An accepted setting is not an enforced retention, privacy, or search control.

Verify the active behavior in this guide. Before you enable capture, enforce necessary retention and data classification rules through supported controls.

Set active values through the owned agent configuration or control manifest.

Register a working scope

POST /v1/context/register registers or updates the session for the authenticated user. The request has these values:

• The request includes session_id.
• The request includes a repository.
• The request includes a branch.
• The request can include a commit.
• The request can include a work directory.
• The request can include a team scope.

When the repository or branch changes, register again.

A branch change creates a new History session relationship. The system identifies the work as a different branch scope.

Do not use only a repository name as a security boundary.

Authentication, organization membership, team scope, and API authorization continue to be necessary.

Capture and share context

The agent mode controls capture behavior. Manual sharing uses POST /v1/context/share.

The request can include session, team, repository, branch, commit, source, tag, verification, and provenance context.

If a request has branch scope, it must also have repository scope. Duplicate detection can return replace, keep both, or discard as a resolution option.

Review the duplicate content. Review its scope. Do not automatically replace the content.

Before sharing:

• Remove secrets and personal data that is not necessary for the task.
• Make sure that the target team and repository are correct.
• Attach useful provenance.
• Classify the content as observed, inferred, or verified.
• Use an exclusion pattern for paths that the gateway must not capture.

PII and DLP controls add protection. They do not authorize collection of content that the organization does not allow.

Search and examine

Endpoint	Purpose
POST /v1/context/search	This endpoint searches authorized team, agent, repository, branch, and session scope.
GET /v1/context/recent	This endpoint lists recent context for a bounded scope.
GET /v1/context/schema/{table}	This endpoint returns context about a named schema or table.
POST /v1/context/graph/query	This endpoint queries governed context graph relationships.
GET /v1/context/graph/entity/{name}	This endpoint returns one graph entity.
POST /v1/context-resolution/inspect	This endpoint returns a staged resolution plan and trace.
GET /v1/context/stats	This endpoint returns statistics for an agent, range, or branch.

Search must have a query unless the request uses the supported agent list mode.

The system excludes disputed content by default. An authorized caller can explicitly request that content.

Direct answers are suggestions. Each direct answer includes source document IDs and confidence.

Preserve those sources. If a source is not verified, do not show its answer as verified.

Resolution inspection redacts content by default. It includes content only when the caller requests it and can view each item.

Build the context graph

Use POST /v1/context/graph/upsert only for authorized graph facts that have a source.

Before you add a duplicate entity, query the graph. Keep the source reference for each relationship.

A graph entry does not show that a fact is correct at this time.

Pair graph results with provenance, confidence, verification status, and timestamps.

Verify and correct context

You can submit these context updates:

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

Use these endpoints:

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

The verification endpoint skips an out-of-scope document. It does not update the document.

Examine the response counts and each document outcome.

Add evidence and scope to each correction. This information makes the new content reviewable.

Do not erase a disagreement only to increase a confidence metric.

Work receipts and reuse

POST /v1/work-receipts captures evidence that software can use again for completed work.

POST /v1/work-receipts/search finds scoped matches. Before the gateway uses a receipt, it evaluates the active governance rules again.

Read Context Fabric Work Reuse for execution behavior, trust states, poisoning defenses, and verifier limits.

The system estimates work that it did not do and its cost from telemetry. These estimates are not invoice data.

Flush completed context

POST /v1/context-flush condenses eligible session context into a recall document that software can use again.

The request uses a History session and context plan hash. A subsequent request for a completed flush returns the stored result.

After the session source material and scope are correct, flush the context. Verify these items:

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

Flush is not an organization-wide deletion operation.

Purge a user's context

DELETE /v1/context/by-user/{id} starts the destructive privacy process for context connected to a user.

It can change 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. Get necessary approval.
4. Capture the pre-operation scope without copying content that is not necessary.
5. Send the delete request one time.
6. Record the response counts.
7. Verify the user is not shown in authorized context searches.
8. Preserve Trail evidence of the operation.

Do not use a context flush to replace a user purge. Do not identify membership removal as an automatic context purge.

Customer and machine API boundaries

This page lists customer routes that use bearer authentication.

These routes have the prefixes /v1/context, /v1/work-receipts, /v1/context-flush, and /v1/context-resolution/inspect.

Machine runtime tokens authenticate routes that have the /v1/gateway/... prefix.

Do not call those routes from customer applications with a human token or ordinary API token.

Next steps

• Read Context Fabric Work Reuse.
• Read Agents in the Console.
• Read API Basics.