Reviews and triage

Reviews and triage organize candidate findings into a queue for human assessment. The queue may be backed by a store or seeded demo data, so the first operational question is provenance rather than priority. Reviewers can compare summaries, severity, evidence, and classification, but assignment persistence, comment persistence, notifications, service-level timers, escalation routing, and role-based permissions were not verified.

Review queue

Begin by checking the queue source. A store-backed queue can represent current records from the supported environment; seeded demo data exists to illustrate review behavior. Sort or prioritize only through controls actually visible in the surface, and confirm the finding’s repository, affected files, severity, and evidence before making a classification decision.

A queue entry without supporting evidence should be returned for investigation rather than advanced through an assumed workflow. The documentation must not invent automatic assignment, reviewer notifications, SLA timers, or role-based permissions.

The queue can contain store-backed records or demo examples. Treat an item as a customer finding only after its source label has been checked. An empty queue is different from an unsupported review path, and neither should be converted into a claim that the repository has no issues.

Open a queue item with its finding and evidence. Do not prioritize only by severity; provenance, confidence, affected code, and repository context also matter.

The queue may contain store-backed records or seeded demo examples. Review queues can load from a backing store or fall back to seeded demo records. Triage should examine severity, evidence quality, affected code, classification, and current status as distinct inputs. A status control in the interface does not prove that every change persists across reloads or environments.

Review queues can load from a backing store or fall back to seeded demo records; identify whether the queue is store-backed or demo-backed. Assignment and comment collaboration behavior requires source verification; use status, assignment, or comment controls only when the current environment confirms persistence. Triage is a human review activity and must not be presented as automatic vulnerability confirmation.

Escalation routing and reviewer roles were not established; open the highest-priority candidate and verify its evidence before changing its review classification. Triage should examine severity, evidence quality, affected code, classification, and current status as distinct inputs; keep remediation discussion separate from a claim that Sentinel applied a change. Treat triage as human review rather than automatic vulnerability confirmation.

Triage

Triage compares the candidate claim with its evidence and repository context. A reviewer may confirm that the issue is credible, identify missing context, classify it as a likely false positive, or return it for deeper analysis. Severity, confidence, status, and classification should be considered separately; changing one does not automatically determine the others.

The queue’s provenance affects what can be changed. Store-backed records may support persistence through audited actions, while seeded demo records only demonstrate the interface. Do not promise that assignment, comments, notifications, or status changes survive a reload unless the current environment exposes and verifies the corresponding store behavior.

Triage is the human process of deciding what a candidate finding represents and what should happen next. Read the summary, inspect the affected files, follow evidence references, and compare severity with confidence.

Sentinel remains defensive and read-only. Do not attempt credentials, exploit a live service, or perform destructive tests to confirm a candidate. When more validation is required, use a separately authorized process.

Record the reason for the triage conclusion. A concise explanation is more useful than changing a badge without context, especially while status persistence remains under review.

Human triage evaluates a candidate finding rather than automatically confirming it. Assignment and comment collaboration behavior requires source verification. No notification or SLA contract appears in the inspected bundle. Escalation routing and reviewer roles were not established.

A status control in the interface does not prove that every change persists across reloads or environments; open the highest-priority candidate and verify its evidence before changing its review classification. Escalation routing and reviewer roles were not established; keep remediation discussion separate from a claim that Sentinel applied a change. Collaboration details remain draft documentation.

Review queues can load from a backing store or fall back to seeded demo records. Use status, assignment, or comment controls only when the active environment confirms persistence. Assignment and comment behavior still requires source verification, so collaboration details remain draft documentation.

Status changes

Before changing a status, confirm that the control writes to the active data source rather than updating only local interface state. Record the reason for the decision in the supported review mechanism, if one exists. Do not invent a permanent audit trail when persistence has not been verified.

A status change can communicate review progress, but a complete state machine and durable mutation contract remain unverified. Do not document every visible control as a persisted action.

If the current environment confirms that a change is stored, use the supported values shown by that build. Otherwise preserve the reviewer’s decision in the organization’s established tracking system. Avoid inventing resolved, accepted-risk, suppressed, or reopened states.

Status remains separate from classification and severity. Changing status does not alter the evidence or prove that remediation occurred.

Visible status controls do not prove durable mutation across all environments. Patch proposals remain separate demo or fixture review artifacts with no durable proposal store. Use status, assignment, or comment controls only when the current environment confirms persistence. Keep remediation discussion separate from a claim that Sentinel applied a change.

No notification or SLA contract appears in the inspected bundle; use status, assignment, or comment controls only when the current environment confirms persistence. Review queues can load from a backing store or fall back to seeded demo records; escalate through the organization’s established process rather than an invented Sentinel notification path.

A status control in the interface does not prove that every change persists across reloads or environments; keep remediation discussion separate from a claim that Sentinel applied a change. Escalation routing and reviewer roles were not established; identify whether the queue is store-backed or demo-backed.

Assignment

Assignment can help establish review ownership, but assignment fields, permissions, persistence, and notifications were not verified. Do not promise that selecting a person creates a durable task or alerts the assignee.

When the interface provides an assignment control, verify its behavior in the current environment before relying on it. For operational work, maintain ownership in an approved system if Sentinel cannot prove persistence.

Avoid inventing role names or access levels. Repository authorization and product access do not automatically define who may review every finding.

Reviewer assignment behavior and persistence require additional source coverage. Escalate through the organization’s established process rather than an invented Sentinel notification path. Identify whether the queue is store-backed or demo-backed.

Patch proposals remain separate demo or fixture review artifacts with no durable proposal store; keep remediation discussion separate from a claim that Sentinel applied a change. A status control in the interface does not prove that every change persists across reloads or environments; identify whether the queue is store-backed or demo-backed.

No notification or SLA contract appears in the inspected bundle. Use the organization’s established escalation process rather than assuming Sentinel sends alerts. Open the highest-priority candidate and verify its evidence before changing its review classification; assignment behavior remains under review.

Comments

Comments are not a verified collaborative record. Use only a comment control whose persistence and audience are clear in the active environment.

Comments can preserve reasoning, but the inspected bundle does not establish comment storage, editing, deletion, visibility, mentions, or notifications. Treat comment controls as under review until their backing actions are sourced.

Do not paste secrets, full proprietary code, credentials, or unnecessary personal information into review notes. Link to authorized evidence where possible and summarize only the context needed for the decision.

A missing comment after reload may reflect unsupported or non-persistent behavior rather than user error. Keep important review conclusions in an approved durable system.

Comment storage, visibility, and notification behavior are not verified. Open the highest-priority candidate and verify its evidence before changing its review classification.

Triage should examine severity, evidence quality, affected code, classification, and current status as distinct inputs; escalate through the organization’s established process rather than an invented Sentinel notification path. No notification or SLA contract appears in the inspected bundle; open the highest-priority candidate and verify its evidence before changing its review classification.

Escalation

Escalation should carry the finding ID, repository reference, data-source label, evidence gap, and current classification. Exclude source secrets and avoid claiming that Sentinel delivered a notification or created a durable case.

Sentinel does not define a complete escalation route, SLA, or notification contract. Use the organization’s existing security process when a finding requires urgent attention, legal review, privacy review, or engineering ownership.

Include safe finding and scan identifiers, repository scope, severity, evidence summary, confidence concerns, and current source label. Do not attach demo findings as customer incidents or include sensitive snippets that are not necessary.

Escalation does not change Sentinel’s boundary. It does not authorize source mutation, public disclosure, live-target testing, or credential use. Patch proposals remain review aids and must be transferred into a normal engineering workflow before any code change occurs.

Organizations should use their established security process because Sentinel escalation routing is not defined.

Assignment and comment collaboration behavior requires source verification; identify whether the queue is store-backed or demo-backed. Patch proposals remain separate demo or fixture review artifacts with no durable proposal store; use status, assignment, or comment controls only when the current environment confirms persistence.