Skip to content

How it works — the observation pipeline

Everything Chronity does flows from one mechanism: the observation pipeline. Understand this page and the rest of the documentation falls into place.

The shape of it

A surveyor works in Claude
        │
        ▼
Claude performs an action through Chronity   ──►   an OBSERVATION is captured
(draft an email, create an event, …)               (encrypted, immediately)
        │
        ▼
Overnight, Chronity CLASSIFIES it against
your firm's signed taxonomy (MIA)
        │
        ├──►  Track 1  ──►  an auto-drafted RELIABILITY FILE NOTE
        ├──►  Track 2  ──►  pooled for quarterly DIP-SAMPLING
        └──►  Track 3  ──►  logged only
        │
        ▼
Awareness, not workload:  daily DIGEST · portal DASHBOARD · real-time ALERTS
        │
        ▼
Quarterly:  DIP-SAMPLE · RISK REGISTER · AUDIT REPORTS      Always:  the AUDIT TRAIL

1. Capture — the moment something happens

Claude connects to Chronity over a standard MCP connection. At the wire level Claude sees only three tools — get_context, search, and execute — through a pattern called Code Mode. Behind those, Chronity exposes a small set of write actions Claude can take on Microsoft 365: drafting an Outlook email, creating a calendar event, sending a Teams message. (Anthropic's own connectors handle reading email, files, and the calendar — Chronity deliberately doesn't duplicate that.)

Every time Claude calls one of those Chronity actions, an observation is recorded server-side, immediately, and the summary is encrypted with your firm's key before it touches storage. This is fire-and-forget — it adds no delay the surveyor can feel.

There is a second, lighter capture layer: Claude can call record_observation to note why it did something — the reasoning behind a piece of work that used only read tools Chronity can't see directly. With the standard Cowork instructions in place, this happens reliably.

2. Classify — overnight, against your own rulebook

Once a night (02:00 UTC), Chronity works through everything captured that day. Each observation is classified in passes:

  1. Deterministic rules catch the clear-cut cases — tool, department, obvious data patterns (UK postcodes, financial figures).
  2. A use-case detector matches the observation to one of your firm's signed use cases from the taxonomy — letting particulars, rent review cross-checking, client email drafting, and so on.
  3. A deterministic mapper looks that use case up in your signed taxonomy and applies the track and sensitivity the taxonomy assigns. The AI only recognises which use case applies; your signed document decides what it means.

Every observation comes out with a sensitivity (public, internal, confidential, restricted) and a track:

  • Track 1 — a formal deliverable. The firm takes professional responsibility; a named qualified surveyor stands behind it.
  • Track 2 — routine professional work using judgement. Reviewed by dip-sampling, not one by one.
  • Track 3 — non-material (platform plumbing, terminology lookups). Logged for completeness, nothing more.

See the Glossary for precise definitions of each.

3. Document — the reliability file note

For every Track 1 observation, Chronity auto-drafts a first-person reliability file note overnight: a short written reliability decision that names the responsible surveyor, references the relevant section of your MIA, and applies the standing reliability analysis your taxonomy holds for that use case. Where a trainee did the work, the note names their supervising qualified surveyor instead.

This is the artefact the RICS Standard asks for, produced without anyone writing it by hand. The surveyor can add an addendum if a point needs clarifying. Full detail: Your reliability notes.

4. Be aware — without a queue

Nobody has to do anything for the record to exist. Awareness comes through three channels, none of which is a task list:

  • A daily digest email (07:00 your time) summarising the previous day's AI activity in each supervisor's and admin's scope. Skipped entirely if there's nothing to report.
  • The portal dashboard — the live picture, any time you want it.
  • Real-time alerts for the rare high-signal exceptions: restricted data in an unapproved place, anomalous volume, an opt-out breach. See Your alerts.

The only thing resembling a queue is the quarterly dip-sample of Track 2 work, which the Standard specifically asks for.

5. Prove it — quarterly and on demand

  • Dip-sampling picks a defensible random sample of Track 2 work each quarter for review.
  • The quarterly risk register is auto-drafted from the quarter's patterns; the AI Lead edits and signs it.
  • Audit reports compile observation counts, classification metrics, sign-off rates, and dip-sample results for a quarter or a year.
  • Observations older than 90 days are archived (encrypted) but stay queryable for an audit.

Two signals that prove the plumbing is alive

Because the Standard depends on the record actually being written, Chronity runs two independent health checks so a silent failure can't go unnoticed:

  • The heartbeat — Claude quietly pings Chronity at the start of every conversation, over plain web access, completely separate from the MCP connection. If the pings keep arriving but observations stop, that's the signature of a dropped connection, and the firm's admin is told.
  • The Daily Check — each weekday morning a scheduled task proves the Microsoft 365 write path still works end to end, by creating and immediately deleting a throwaway draft. The result shows on each user's Daily Health page.

Neither needs any attention day to day. They exist so that "the audit trail went quiet" is something the system notices, not something you discover at the next inspection.

Next: Roles & who sees what explains who can see which records, and the Glossary defines every term used above.