What a semantically pure signal is
A semantically pure signal is a record with explicit state: you know when it was detected, whether a human reviewed it, and whether a model generated an analysis on it. It isn’t a free-text paragraph, it’s a row with verifiable fields. That’s what makes it ready to hand to an AI model without risking a hallucination: the model doesn’t have to infer the data’s provenance, the provenance is already in the record.
Anatomy of a signal
The real audit fields of a signal, not a simplified example, are these:
revsign.os/signal
$ curl revsign.os/signal/8f2a1c
→ {
company_domain: "acme.com",
signal_type: "tech_stack_change",
intent_score: 82,
status: "pending",
approval_status: null,
date_detected: "2026-07-14T09:00:00Z",
reviewed_by: null,
reviewed_at: null,
insight_status: "pending",
version: 1
}
# Note: there are no "ingested_at"/"validated_at"/"logged_at" fields,
# the real chain is date_detected → approval_status/reviewed_at → insight_status.Chain of custody: detection → review → insight
date_detected marks the moment it was loaded. approval_status and reviewed_by/reviewed_at are the explicit human-approval checkpoint, a signal doesn’t move to action without that field being set. insight_status, along with insight_attempts and insight_model, records whether and how a model generated further analysis on the already-approved signal. Every stage lives in the same row, not in a separate log that can go missing.
How the context fed to the model gets assembled
- Signals are filtered by
status != 'suppressed'and by the intent band relevant to the query. date_detectedandapproval_statusare attached to every signal included in the context, so the model can cite the date and review state, not just the content.- Signals without
reviewed_atare excluded from any context meant to produce an actionable recommendation, only what a human has already reviewed gets used for decisions, not for exploration. - The full record is handed over, not a summary: the model receives the fields, not a paraphrase of the fields.
Generic document search vs. validated signals
| Dimension | Generic document search | Validated signal injection |
|---|---|---|
| Origin | Documents of any age, no state | Rows with an explicit date_detected |
| Freshness | Depends on when the document was indexed | Verifiable by a direct field query |
| Verifiability | The model can’t distinguish fact from opinion | The approval_status field distinguishes reviewed from pending |
| Behavior on contradiction | The model can cite two contradicting sources unknowingly | Only one record per signal, and conflict status excludes it beforehand |
| Text volume | Full documents or long fragments | One compact, structured record |
Known limits
This doesn’t solve everything. Intent-score quality depends on software-detection coverage, an unmonitored tool category can’t show a change. The conflict filter operates at the company-domain level, not at the individual-contact level. And that human-approval checkpoint means no signal reaches an AI model in production without a human having reviewed it at some point, that’s a deliberate design decision, not a limitation to be solved.
$ curl revsign.os/docs/data-injection-for-llms
→ {
title: "AI-Ready Data: Anatomy of an Auditable Signal",
answers: "How do I give an AI model auditable data about my own company?",
schema: [TechArticle, HowTo]
}