Skip to main content
Classification Methodology

How TokenScope classifies requests

TokenScope determines whether each Claude Code request is on-scope, off-scope, or policy-relevant — and applies the configured action. This page explains how that process works and where its limits are.

What classification is for

Classification helps organizations govern how Claude Code is used on company time and with company-funded access. It is not a productivity measurement or performance-review tool.

What it helps with

  • Understand whether usage aligns with business context
  • Identify requests that appear unrelated to company-funded work
  • Apply configurable policies to request types
  • Surface uncertain requests for administrator review
  • Reduce avoidable cost from off-scope usage
  • Support audit and compliance reporting

What it is not for

  • Measuring developer productivity
  • Evaluating the quality of work output
  • Performance management decisions
  • Real-time employee monitoring beyond governance scope
  • Inferring intent from limited context

How project scope is defined

Scope is defined by administrators through workspace and project configuration. There is no automatic inference of scope from unreviewed sources.

Workspace configuration

Administrators configure the overall governance context for the workspace, including default policy behavior.

Supported

Project descriptions

Each project can include a description that informs classification for requests attributed to that project.

Supported

Team ownership

Requests are attributed to teams based on the developer's project and team assignment.

Supported

Cost-centre assignment

Cost centres define organizational units. Attribution to a cost centre provides additional context for policy evaluation.

Supported

Administrator-defined policies

Policies specify which request types are allowed, warned, or blocked per project or workspace.

Supported

Classification flow

Every request processed through the TokenScope proxy goes through the following steps before being forwarded to the Anthropic API.

  1. Request context received

    The proxy receives the request from the developer's launcher session, including attribution metadata (developer identity, project, team).

  2. Policy identified

    The applicable workspace and project policy configuration is loaded for the authenticated developer and project.

  3. Classification checks performed

    The request is evaluated against the configured scope and policy rules. In full-content mode, prompt content may be reviewed. In metadata-only mode, only request metadata is used.

  4. Confidence score produced

    A confidence level is assigned to the classification decision. Requests with low confidence are treated according to the configured fallback behavior.

  5. Configured action applied

    Based on the classification result and policy mode — Observe, Alert, Warn, or Enforce — the request is allowed to proceed, flagged, or blocked.

  6. Decision recorded

    The classification result, confidence level, policy decision, and action are recorded in the audit trail.

Confidence and uncertainty

Not every request can be classified with high confidence. TokenScope handles uncertain cases through configurable fallback behavior.

Classification is a policy-assistance mechanism and may require administrator review in ambiguous cases. It is not a definitive determination of intent.

Confidence thresholds

Each classification decision includes a confidence score. Administrators can configure how low-confidence results are handled — typically by defaulting to the less restrictive of the two possible classifications.

Uncertain classification

When the classifier cannot determine scope with sufficient confidence, the result is marked as uncertain. The configured fallback policy applies — by default, uncertain requests are allowed and flagged for review.

Fallback behavior

Administrators configure what happens to uncertain requests: allow and record, warn the developer, or hold for review. The default is to allow and record, which is appropriate when starting in Observe mode.

Processing overhead

Classification adds a small amount of processing time to each request. The impact on Claude Code use is not typically noticeable.

  • Policy evaluation runs within the TokenScope proxy before the request is forwarded to Anthropic.
  • Classification does not require a separate round-trip to an external model for most policy checks.
  • Total added latency is small relative to the Anthropic API response time.
  • Classification overhead may vary based on policy complexity and request size.

Data handling during classification

What data is used during classification depends on the workspace storage mode.

Full content mode (default)

  • Prompt content is available for content-based classification
  • Classification can evaluate the meaning and context of the request
  • Prompt text is stored per the configured retention period
  • Access to prompt text is restricted by role

Metadata-only mode (Privacy Mode)

  • Prompt text is never stored or used for content-based classification
  • Classification relies on request metadata only
  • Attribution, project context, and policy rules still apply
  • Available on Team plan and above

Storage mode is configured per workspace. See Privacy for Teams for the full storage and retention explanation.

Known limitations

Classification is not infallible. The following scenarios can produce incorrect or uncertain results and should be reviewed manually when governance accuracy is critical.

  • Ambiguous or exploratory research

    Broad research queries that span business and personal topics may not classify reliably. Administrators should expect some false positives in this category.

  • Multi-purpose prompts

    A single prompt that mixes on-scope and off-scope content may be classified based on the dominant signal. Partial-scope requests are not split.

  • Custom organizational terminology

    Domain-specific terms, internal product names, or uncommon business vocabulary not reflected in the project configuration may reduce classification accuracy.

  • Incomplete project context

    If a project description is missing or too generic, classification has limited scope context to work with. More specific project descriptions improve results.

  • Natural-language complexity

    Indirect phrasing, metaphor, or non-standard sentence structure can reduce classifier confidence. These cases typically fall to the configured fallback behavior.

Review governance controls

See how policies, enforcement modes, and storage controls work together to give your team the right level of governance.