CUI classification offers a substantial reading problem with repetitive work and errors whose consequences can be described and tested. The task already exists in the organization, giving an engineering team a place to evaluate what a model can contribute alongside the software responsible for reviewing, marking, and moving the information.
A fifteen-second demo tends to show a model highlighting a paragraph and assigning a label, leaving the category context, source evidence, review decision, and subsequent handling largely unexplained. Those responsibilities are harder to present quickly, but they determine whether the classifier can support the work people actually need to complete.
The infrastructure interests me because the document continues through reports, generated summaries, spreadsheet exports, and other workspaces after inference finishes. A classification system needs to preserve relevant context across those transitions, allowing an operator to understand how a determination on the source affects the next artifact and proposed action.
Controlled Unclassified Information is unclassified information governed by applicable safeguarding and dissemination controls. In this workflow, a model can identify candidate categories and prepare evidence for a determination, while the applicable authority and handling obligations come from the governing context. The application needs to keep those responsibilities distinct throughout review and subsequent use.
NARA's government-wide CUI program publishes marking and handling resources, while NIST SP 800-171 Rev. 3 addresses protection of CUI in covered nonfederal systems. The deployment team needs to consider that handling context across the workflow, including the operations that follow a detection result.
Agency, contract, category, and legal context can affect a CUI determination, so the workflow must make the relevant context available before treating a candidate as decided. Where that information is missing, the system should identify the gap and route it for resolution rather than interpreting a high model-confidence score as sufficient authority.
The ambiguity is real, and so is the limit
Semantic detection can help where information is expressed indirectly, spread across passages, or buried in attachments that a regular expression would not recognize reliably. A model can connect candidate passages to a supplied category profile, giving the reviewer material to examine with the applicable context in view.
An unrestricted question about whether an arbitrary document contains CUI leaves the relevant categories, source and contract context, supporting evidence, and review authority unspecified. The detection task should be scoped around those inputs, with any missing information recorded so the resulting suggestion does not conceal an unresolved dependency.
The model's job should be to find material that may match the applicable profile and identify the passage or field supporting that suggestion. An explanation can help the reviewer understand the relationship, provided it remains connected to the evidence and clearly represents uncertainty or missing context.
Known identifiers and explicit policy rules can be checked deterministically, with their results recorded alongside the semantic model's findings. Where the two methods disagree, preserving both results helps the reviewer understand the conflict and gives the team evidence for evaluating either detector, which a combined score could obscure.
A document might contain an identifier in an attachment and a narrative description in its main body, allowing a deterministic detector to locate the identifier while a model proposes a category match for the description. The reviewer needs both findings, their relationship, and the applicable profile to evaluate the case. Retaining the separate evidence lets the workflow support that determination without allowing either detector's narrow result to stand in for it.
Source references should identify the document version and location behind each finding, including a path back to the original scanned page where text extraction was used. That connection allows the reviewer to detect reading errors and examine the evidence in context, rather than relying on an explanation built from incorrectly extracted text.
A fluent rationale can appear more authoritative than its inputs warrant, especially when the reviewer can read the explanation more easily than inspect the extraction process. Placing the source evidence beside it makes verification practical and keeps the explanation in its intended role of helping the person understand a candidate.
Review needs a usable case
Human review requires an interface and workload that let the person exercise judgment, with access to the evidence and context needed for the particular case. Adding an approval button leaves that design work unfinished if the reviewer still has to reconstruct the detector's reasoning and locate the governing material independently.
A reviewer needs to know what is being proposed and what remains uncertain. The case should connect the source artifact, the triggering evidence, the candidate category, and the applicable policy profile. It should distinguish a model suggestion from a confirmed determination. Where human confirmation is required, the workflow has to wait for that confirmation before treating the proposal as decided.
The practical goal is to reduce the searching that surrounds judgment. A person who has to reread the whole document, locate the relevant contract context, discover why the detector fired, and reconstruct the proposed marking has received another task rather than meaningful assistance. A good review surface puts those materials within reach without pretending they all fit inside a single score.
A reviewer also needs a way to reject the proposal and explain why. That explanation may reveal a bad detector, an incomplete profile, or a misunderstanding that will recur in other documents. If every rejection disappears into a boolean field, the team loses a valuable account of its system's behavior.
Changes to a source document or policy profile can alter how the evidence should be interpreted, so the determination record needs to identify the versions reviewed. A correction should preserve the previous outcome and explain what changed, giving the application a basis for deciding whether further review is needed and helping the operator distinguish the current case from its history.
Keeping evidence, authority, and outcome distinguishable makes the decision record easier to maintain through corrections and detector changes. The evidence describes what was found, the authority establishes the applicable context and process, and the outcome records the determination that process produced. An operator should still be able to interpret that record after the classifier has been replaced.
The label has to survive useful work
After confirmation, the application can render the applicable marking deterministically from the decision and its rules. A defined renderer makes the banner and supported marking formats consistent and testable, while keeping the model's interpretive role separate from the code responsible for producing the approved representation.
Summaries, extracted tables, merged reports, and transformed records can carry information from protected sources, requiring the workflow to retain those relationships for evaluation under the relevant policy. Changes in wording alone do not establish a new handling status, so the derivative needs to pass through the appropriate determination process before the application treats it as ready for use.
The derivative still needs evaluation under the applicable context and authorized process, since its relationship to the source alone may not settle the required treatment. Retaining provenance gives the reviewer a basis for that evaluation and avoids assuming either that changed wording removes all handling obligations or that every derivative must receive identical treatment indefinitely.
A transformation should retain the source versions used, what was extracted or summarized, and any unresolved handling questions. Extracted table fields may map directly to source locations, while a generated summary may need references to several passages. The implementation should preserve enough of that relationship for an operator to reconstruct the basis of the derivative and obtain any required review.
Destination checks need to evaluate the proposed movement against the permitted handling context, even when the artifact has been correctly marked. The suitability of a workspace or tool depends on its approved use for the information involved, rather than its name or technical ability to receive a file, so the transfer should remain subject to an explicit check before execution.
An external classifier receives information during inference, making the approved processing path part of the handling design from the start. Model selection needs to follow the environment's requirements for that material, including where it can be processed and which endpoints are permitted to receive it.
Routing needs to be included in a product's account of what it controls because it determines where information goes after detection and review. A system that evaluates content but leaves every subsequent send to an unchecked integration cannot establish that the resulting workflow handles the document appropriately.
Evaluate the queue, including the inconvenient parts
Evaluation should cover both missed candidates that can contribute to mishandling and unnecessary flags that consume reviewer attention or restrict legitimate use. The consequences depend on the surrounding workflow, including whether another check catches the missed material and how much investigation each false alert requires.
Flagging everything is an easy way to produce an impressive recall story and an unusable workflow. The resulting review backlog becomes part of the system's cost. If reviewers routinely dismiss repetitive, poorly supported suggestions, the interface has trained them to expect noise. A detector should be evaluated with the people who have to resolve its output in mind.
Use representative documents with adjudicated outcomes and retained context. An evaluation set consisting only of obvious positive examples tells the team very little about the boundary cases. Include documents that resemble a category without satisfying the applicable determination, documents with incomplete context, and cases where the correct operational result is to request review rather than assert an answer.
The evaluation should follow the findings through source inspection, profile selection, required confirmation, rendered markings, derivative provenance, and destination checks. Testing those stages together reveals failures a narrow classifier score would miss, while preserving separate results helps the team identify which component needs correction.
Dependency-failure testing should establish that the application retains its source, gathered evidence, and pending review state when inference is unavailable. Deterministic checks may be able to continue while ambiguous decisions wait, with fallback restricted to processing paths already approved for the material involved.
Reviewer effort, rework, completed cases, and handling failures give the team a practical basis for deciding whether this workflow is ready for deployment. Those measures connect the classifier's contribution to the actual process and reveal whether improved detection is being offset by review burden or failures later in the chain.
Information needs to be interpreted in context, reviewed where required, marked, transformed, and moved, with each handoff retaining the relationships needed for the next step. AI can reduce reading and searching within that sequence when the application preserves the evidence and keeps the appropriate owners involved in unresolved decisions.
Procurement evaluation should therefore include rejected candidates, corrected determinations, and derivatives passing through destination checks. Following an operator as they resolve those cases shows whether the evidence remains usable and whether the application provides the controls needed to complete the work without rebuilding its history.
Have a challenge we can help with?