Muhammad Atashi
Automation · state reconciliationPRIVATE COREV8.1

Centris Property Monitoring

A stateful monitor for a restrictive external real-estate source: it verifies the complete listing set before trusting it, reconciles every observation against persisted state, classifies NEW and PRICE CHANGE transitions, commits state before notifying, and delivers controlled Telegram alerts across isolated failure boundaries.

Owns
Reconciles full listing sets before any notification ships
Status
Operational stateful monitor · full-set reconciliation · Telegram delivery
Stack
n8n · REST · Google Sheets · Telegram · JavaScript

Personal automation project with artifact-level operational evidence; the implementation is not publicly released.

Hard problem

Discovery, classification, persistence, and notification should remain separate failure boundaries.

Question · Did the monitored market state actually change?

APPLIES TO

Property monitoring workflows · Automation engineering · Stateful notification systems · n8n operational automation

PROOF

v8.1 · 28-node stateful workflow · full-set reconciliation · observed NEW + PRICE CHANGE Telegram delivery

CAPABILITIES

11 declared in the project record

  • Scheduled full-set discovery
  • Session-aware source requests
  • Pagination coverage gates
  • Persisted state reconciliation
  • NEW/PRICE change classification
  • State-overlap safety checks
  • Detail validation
  • Bounded processing
  • Persist-before-notify semantics
  • Telegram delivery state
  • Source-contract drift handling

Operational proof

Source to alert.

Centris listing page for a monitored quintuple property priced at $1,825,000
Source listingMonitored · $1,825,000
Telegram channel showing a new Centris listing alert and a subsequent price-change alert for the same property
Telegram alertsSame listing · NEW, then PRICE CHANGE
Canonical runv8.1 · 28 nodes · 9 code nodes
01

Discovery boundary

Session context and request contract are established against the external source before any listing data is read.
Contract failureCycle ends here — nothing reaches reconciliation.
02

Completeness checks

Pagination cardinality and overlap with persisted state are verified before the discovered set is trusted.
Incomplete setNot a market event — the cycle produces no alerts.
03

Detail validation

Each candidate record goes through per-listing enrichment behind data-quality gates.
Invalid recordSuppressed for the cycle — no false alert.
04

State reconciliation

The observed set is diffed against persisted listing state held in Google Sheets.
Boundary behaviorOnly deltas between cycles generate events.
05

Classification

Every difference resolves to exactly one class: NEW, PRICE CHANGE, or UNCHANGED.
UnchangedSilent by design.
06

Persistence

Reconciled state is committed before any external side effect is emitted.
Ordering invariantCommit always precedes notification.
07

Controlled notification

Telegram alerts are paced deliberately and each delivery outcome is recorded.
Delivery failureRecorded — no re-alert next cycle.

Valid runSource contract satisfied and completeness checks passed; only then is the observed set reconciled against persisted state.

Contract failure

Run is invalid: no reconciliation, no state mutation, no notification.

Incomplete result set

Incomplete acquisition, not a market event — no classification, no mutation, no notification.

Invalid record

Suppressed before reconciliation: no mutation for that record, no notification.

UNCHANGED

A valid, successful run with nothing to announce: no write, no notification.

Persistence failure

Mutation does not commit, so nothing is notified — notification only ever follows a successful commit.

Delivery failure

State stays committed and the listing is not rediscovered as NEW next cycle; delivery is a downstream failure, not a market event.

Reconciliation model

A poll is not an alert.

State reconciliationEvery cycle · every observed record
  1. 01

    Observe

    A record arrives from the source boundary during discovery.
  2. 02

    Normalize identity

    Reduced to the stable listing identity reconciliation matches on — never raw page content.
  3. 03

    Compare with state

    Matched against persisted state: known or unknown, price versus last recorded value.
  4. 04

    Classify

    The diff yields exactly one outcome. There is no fourth class.
Resolves to exactly one outcome
NEW
No row in persisted state — first observation of this property.
Recorded as known, then notified.
PRICE CHANGE
Known identity whose observed price differs from its persisted value.
Persisted price updated, then notified.
UNCHANGED
Known identity whose observed state equals its persisted record.
No write, no message — silence is correct output.

Engineering decisions

The constraints that matter.

01

Trust the set only after coverage checks

A successful partial response cannot become the market truth without pagination and cardinality validation.

02

Persist before notification

External notification failure must not make a known listing look new on the next cycle.

03

Separate source health from listing state

A scrape/data-quality failure is not a real-estate event and must not create false alerts.

Measurement contract

What would make the preferred answer fail?

EVALUATION METHOD

A monitoring run is successful only when the observed market set is complete enough to reconcile state without false new/change alerts.

Full-set pagination checks, state-overlap gates, source-contract regression fixtures, notification replay, and end-to-end listing-to-alert verification.

01

Set coverage

discovered count vs planned pages
02

Cycle latency

schedule → reconciled state
03

Change fidelity

NEW / PRICE / unchanged classification
04

Duplicate alerts

repeat-notification prevention
05

State integrity

persist-before-notify semantics
06

Delivery

Telegram delivery status

Validation

What the evidence actually supports.

Claims stay scoped

Workflow nodes

VERIFIED

28

Static audit of the packaged v8.1 workflow.

Code-node syntax

VERIFIED

9 / 9

Syntax validation only; not live workflow execution.

Reachability

VERIFIED

28 / 28 nodes reachable from triggers

Static workflow graph audit.

Centris request contract

VERIFIED

HTTP 200

Single sampled live debugging response.

Operational notification

VERIFIED

NEW LISTING + PRICE CHANGE delivered to Telegram

User-provided operational capture from the monitored workflow.

Source-to-alert match

VERIFIED

$1,825,000 listing state appears at source and downstream alert

The public case study uses a single sanitized observed property as an artifact-level trace, not a market-wide accuracy claim.

Boundaries

— Not a market-wide data product— No claim of bypassing source security controls— No guarantee that an external site will keep a stable private contract— No private credentials exposed in the public case study
← Selected systemsNext · AgentGuard