Skip to content

Optional analytics

Allow optional analytics to help improve projects, writing and navigation. It uses a pseudonymous first-party identifier after consent. No names, email addresses, messages or search text are collected.

Read the privacy policy
Allen Manoj
← All work
Case studyOpen-source monitoring systemOpen source

Sentinel

Turns changing web information into evidence-backed alerts and briefings.

An open-source AI monitoring system for teams that need evidence-backed intelligence rather than raw web alerts. Tracks meaningful changes across companies, people, topics, and URLs with source evidence and importance scoring.

Discuss a similar systemOpen current buildView source
Evidence feed
01source capturedok
02change scored91
03alert routedok
My role

System architecture, backend workflow, monitoring logic, and intelligence interface

Project stage

Open-source current build

What it replaces

Replaces noisy monitoring feeds with scored changes, source evidence, and useful escalation.

Current evidence

Open current build · View source

01
Overview

What the system is meant to change.

For

Teams that track companies, people, topics, or pages and need important changes separated from noise.

Replaces

Web monitoring tools generate noise. They surface raw changes without evidence, context, or any signal about which updates actually matter. Teams end up with another feed to check rather than intelligence they can act on.

Produces

Evidence-backed change alerts with an importance score, source context, and enough detail to decide whether a change matters and what should happen next without reading through unfiltered monitoring feeds.

02
Architecture

Use AI after the change is proven, not to decide whether a change exists.

Sentinel schedules configured watches, retrieves source content, canonicalises noisy pages, compares the result with prior state, preserves evidence, and uses AI only after deterministic change detection to evaluate significance and route alerts.

01
Schedule
02
Retrieve
03
Canonicalise
04
Compare
05
Evaluate
06
Persist
07
Alert
01

Source watch

02

Evidence and significance

03

Routed alert

Design constraints
  1. 01Canonicalise dynamic content before comparing page state.
  2. 02Persist source evidence before asking a model to judge significance.
  3. 03Separate retrieval, comparison, evaluation, persistence, and notification retries.
  4. 04Suppress duplicate alerts without hiding a genuinely new change.
Engineering decisions
  1. 01Canonical content: Source-specific cleanup removes known dynamic regions before a comparison is created.
  2. 02Evidence first: Before and after evidence is stored before significance evaluation or alert generation.
  3. 03Persistent watch state: The comparison history survives worker restarts and supports later review.
  4. 04Separate retry boundaries: A failed notification does not require retrieval and significance evaluation to run again.
System behaviour and reliability
  1. 01Monitoring definitions establish what should be checked and when.
  2. 02Retrieved content is canonicalised before comparison.
  3. 03Deterministic change detection identifies candidate differences.
  4. 04Source evidence is persisted before AI significance evaluation.
  5. 05High-priority changes are routed through configured channels.
  6. 06Persistent state allows comparisons to survive worker restarts.
  7. 07Duplicate suppression prevents repeated alerts for the same evidence.
  8. 08Retrieval and notification failures remain separate retry boundaries.
Evaluation approach
  1. 01Test canonicalisation against dynamic and stable page regions.
  2. 02Measure change-detection precision and duplicate-alert rate.
  3. 03Review AI significance decisions against human-labelled examples.
03
Visual proof

Interface views for the workflow and its decisions.

Design representation — replace these views with production screenshots as the product matures.

Evidence-backed alert feed
Evidence feed
01source capturedok
02change scored91
03alert routedok
Evidence-backed alert feed

The alert surface leads with captured evidence, significance, and routing state.

Change inspection
Pricing page changed
captured 14:32 AEST
significance 91
Before

Team plan includes 10 projects and standard support.

After

Team plan includes unlimited projects and priority support.

Source evidence saved before significance evaluation
Change inspection

A proposed review view keeps the source difference and the model’s significance judgement separate.

04
Evidence and boundaries

What exists now, what remains limited, and what comes next.

This separation is intentional: planned evaluation and reliability work is not presented as completed evidence.

Limitations

  1. 01Significance evaluation remains dependent on source quality and configured thresholds.
  2. 02Dynamic pages require source-specific canonicalisation to avoid noisy alerts.

Next validation

  1. 01Publish a fixed change-detection test corpus.
  2. 02Measure false positives after dynamic-content removal.
  3. 03Document recovery behaviour for retrieval and notification failures.
05 · Discuss a similar system

Send the current workflow, source material, report, or product idea.

A polished specification is not required. The rough version is enough to establish the problem boundary and useful next step.

Discuss a similar system
Next case studyLens