27 registered watchers pull every upstream on its own cadence and write into the mirror. Nothing downstream ever calls an upstream directly — so a vendor outage costs us freshness, never availability. Cadences shown are the registered job intervals; live run state, failures and next-run are in the Watchers table above.

Mirrored rows are only useful once the same grower in three systems is known to be the same grower. Auto-link takes the certain matches; anything short of certain becomes a suggestion a human accepts or rejects. Derived tables are rebuilt from the raw payloads, never hand-maintained.

Structured data lives in Postgres; anything large, binary or long-lived lives in R2 behind our own endpoints, so a consumer never depends on a vendor URL and we can move storage without breaking an integration.

Field imagery is pulled from AG365 once and served from /dashboard/ag365/field-images/:fieldId/image — re-fetched only when AG365 re-renders the field (its media id changes).

Two things produce writes: an API caller, and the change router noticing a new record upstream. Both land in the same queue. Nothing reaches an upstream system without either a human click or an explicit per-system Auto switch — and money-spending operations always meet a human, whatever the switch says.

One router, many faces. Every consumer goes through the same capability-checked endpoints, and every action any of them takes lands in the audit feed above.

The authoritative NetSuite ↔ AG365 ↔ Monday field map with live implementation status (built / partial / gap) — the standard the build follows.

Nothing below is reachable while Module is Off — the endpoints answer 403, not an empty list. Switch it On above to read boundaries and measure ground.

Every endpoint below is served from our mirror, so a consumer never depends on NetSuite, AG365 or Monday being up. A key carries only the capabilities it was minted with and is never a SuperAdmin — the same permission model the dashboard itself uses.

Badger reads these records from /badger/v1. A record is live while Badger can read it and gone once it is retired (Badger is told, so it can drop its copy). The feed refreshes by itself about every 10 minutes; Refresh now does it straight away.

Badger sends one key with every request. It can read the feed and nothing else. To change keys, create a new one, give it to Badger, then revoke the old one.

Badger sees only the fields switched on here, plus id and lastmodifieddate, which are always sent. A switch changes what counts as a change, so Badger re-reads every record of that object the next time the feed refreshes.

Exactly what Badger receives for one record: the same answer as GET /badger/v1/<object>/<id>, with today's field switches.