SGL
Signal
Analyse and score
What it does
Signal decides whether an input can be trusted. It runs checks on incoming data close to the source, so issues surface before anything downstream takes a dependency on them.
What the automated checks cannot settle is specified to route to a reviewer, who accepts or halts the input, with the decision recorded against it.
What it accepts
The output from Read, checked against rule sets written as code.
- Typed outputs
- The outputs Conduit emits, with their fields and ingest history.
- Checks
- Checks written as code, selected per input type.
What it emits
- Check records
- One record per check binds the input digest, the rule set version, the model and configuration version, the outcome, the reason, the actor and the timestamp.
- Review queue entries
- The cases the automated checks cannot settle, routed to a reviewer with the evidence attached.
How it is configured
Configuration belongs to the client. It encodes what your specialists already know, and it is versioned like code.
- Check selection
- Which checks run against which input types.
- Thresholds
- Where a score becomes a finding and where a finding becomes a routing.
- Routing rules
- What goes to the review queue and to whom.
What it produces as evidence
- Scores and findings
- A scored outcome for every check, with the reason recorded alongside the result.
What it is tested against
Signal is tested against acceptance criteria agreed before build: defined check classes producing the agreed outcome on the agreed cases, every field listed above present in the check record, and the review queue routing what the criteria say it should. One agreed set serves both commercial acceptance and the evaluation record.