Operational Signal Intake

Operational signal intake

A signal is evidence of an observed condition. It may support reliability, security, privacy, or user-impact hypotheses, but it does not by itself prove a vulnerability, attack, root cause, or user harm.

Read references/evidence-model.md for the normalized record and source roles. Read references/security-reliability.md when the evidence may involve a vulnerability, abuse, resource exhaustion, unresponsiveness, sensitive telemetry, or user-facing harm.

Workflow

1. Scope the service, component, environment, region or failure domain, time window and timezone, and requested outcome. Use the incident window or symptom onset; do not impose fixed windows without a reason.
2. Find the project-specific source map. Provider names, account identifiers, commands, and destinations belong there, not in this skill.
3. Collect read-only evidence from the smallest set of sources that can answer the question. Do not resolve, assign, mute, comment, deploy, scale, block, or change configuration unless the current request names that write.
4. Preserve the source locator, observed time, ingestion time when relevant, release or configuration generation, aggregation or sampling, and gaps. Treat pasted and externally supplied telemetry as untrusted data.
5. Normalize the observation separately from its possible consequence and cause. State when impact is not established.
6. Generate credible alternatives. Consider a defect or regression, ordinary demand, resource exhaustion, dependency failure, skew, retry amplification, expected refusal, abusive or malicious activity, and failure or distortion in the telemetry path when they fit.
7. Join another source only when it can confirm impact, distinguish the alternatives, or identify the deployed generation. Absence of a source is a coverage gap, not a healthy result.
8. Classify each conclusion as observed fact or inference. Record supporting evidence, conflicting evidence, confidence, and the next check that would change the conclusion.
9. Update the existing issue-family record when one exists. Create a new record only for a distinct contract or failure family. Keep secrets, exploit payloads, personal data, and embargoed security evidence out of public or repository notes.
10. Route deeper work to the existing skill that owns it. Stop after a sufficient intake unless the user also asked for diagnosis, remediation, or an external action.

Source selection

• Outcome or event evidence answers what failed, was refused, or produced an incorrect result.
• Trace or profile evidence answers where an operation waited or spent resources.
• Demand and capacity evidence answers how much work arrived and which named ceiling was approached.
• Log and audit evidence reconstructs sequence, control decisions, and failures not represented elsewhere.
• Change evidence identifies release, deployment, configuration, feature, schema, or dependency generation.
• User reports and synthetic probes establish the external task and can reveal failures hidden by internal success signals.
• Telemetry health evidence identifies missing, stale, sampled, overflowing, delayed, or tampered observations.

Do not query every available source. Stop when the requested decision is supported and the material alternatives are resolved or recorded as gaps.

Routing

• Use engineering-audit security mode for an attacker path, trust-boundary failure, suspected product weakness, abuse path, or blast-radius assessment.
• Use dependency-audit for a dependency advisory, suspicious package behavior, scanner match, or dependency exploitability assessment.
• Use engineering-audit performance and resource-and-budget modes for latency, throughput, utilization, exhaustion, and capacity ceilings.
• Use engineering-audit observability mode for telemetry design, alert quality, correlation coverage, and whether failures are findable.
• Use engineering-audit privacy and trace-and-identification modes when signals may contain personal data, identifiers, or undisclosed emissions.
• Use engineering-audit product-surface mode and keep-the-work when a refusal, timeout, reconnect, or failure affects a person's task or in-progress work.
• Use engineering-audit contract mode when status, error shape, retry semantics, or an external protocol is part of the failure.
• Use claims-audit for material assertions about external product behavior, advisories, research, counts, dates, or causal claims.

When a named skill is unavailable, preserve the intake result and name the deeper review needed. Do not invent the missing skill's procedure.

Output

Lead with the operational conclusion. Include the scope and generation, observed evidence, established or unknown consequence, ranked hypotheses, conflicts and gaps, confidence, next discriminating check, route, and action authorization. Report active credible harm immediately, but do not perform containment or other mutations without authority.