Assistant & API
AI assistant
What the assistant can read, what it proposes, sessions, and the context and skills it works from.
What the assistant is
The AI assistant is a conversational front door onto your own deployment. Ask it how your sensors are doing, what an alert rule is set to, whether a reading looks wrong, what CEDEN wants in a column — and it answers from the live system, seeing exactly what your account can see and nothing more. When you ask for something to be created or changed it does not change it: it drafts the exact change as a proposal and waits for you to confirm it. Use it when the question would otherwise mean opening four pages, or when you want a second opinion from someone who has read every setting.
It appears once your group has an API key for it. Until then there is no bubble, no link and no page — if this page describes something you cannot find, that is almost always why, and Who can use it below says who adds the key and where. With a key in place it lives in two places. The AI Assistant bubble in the corner of every signed-in page (including the Data quality, rating-curve and CEDEN workbenches) opens a drawer, so a question about a sensor is asked while looking at that sensor; the ⤢ button in the drawer, or the Assistant link on your profile page, opens the same conversation full screen with the Agent context panel beneath it. Both are views of one conversation kept on the server — minimising the drawer (–) discards nothing.
The bubble follows you out of the workbench, too. Signed in, it is in the corner of the public pages as well — the open map, Analytics, the public dashboards, a group's own site, these docs — because that is where the questions it answers best are usually asked. It is the same conversation, billed to the same group's key, seeing exactly what your account sees; standing on a public page grants nothing. Signed out there is nothing there at all, and the shared guest account can read the panel but not send to it.
Who can use it
Every question spends money on somebody's API key, so access follows the key:
- A group's own key. The group owner pastes a key into the Assistant card on the group's page (Groups → the group): provider (Anthropic or DeepSeek), the key (never shown again once saved — leave it blank to keep the stored one), an optional model name, Enabled, and Remove key to switch the assistant off for the group. Members then need the Assistant permission in that group: read to ask questions, read & edit to have it propose changes and to edit the group's context.
- The deployment key. Superusers run on the key your administrator configured for the deployment, and can both ask and propose.
- The guest account can read the panel — the transcript, the context page, the ask box — but not ask: the box is disabled with "Sign in with your own account to ask a question", because the guest is a shared credential.
The caption under the panel's header says which key a conversation is on ("on Group's key" or "deployment key") and "read-only" when your account can ask but not propose. A conversation is bound to its paying group when it starts and stays there.
Which model answers is the provider on that key, and only that. On an Anthropic key a Claude model answers — Claude Opus 5 by default. On a DeepSeek key a DeepSeek model answers — DeepSeek V4 Pro by default, or DeepSeek V4 Flash if you name a model DeepSeek does not recognise, which is why the model box is best left blank there. DeepSeek's endpoint is Anthropic-compatible, so the request is addressed with a compatibility name on the wire; that is routing, and nothing on a DeepSeek key runs on Anthropic. The two also differ in what they accept: images are sent on Anthropic only, and the context panel says so where it matters.
How to ask
Type into the box ("Inspect your system, command your fleet…") and press Ask or Enter (Shift+Enter for a new line; up to 4,000 characters). The button reads Thinking… while it works — answers usually take several seconds because the assistant is reading your data with tools before it replies. A new conversation offers four starters: How is my suite doing?, Which variables have no alert rule?, Set up an alert for me and Any sensors gone quiet?.
Name things the way the app names them — the sensor's site code, a folder name ("the regulatory sites"), a rule's title — and say what you want done with the result. The assistant reads folders, so "the creek folder" scopes an answer to those sensors rather than all of them.
What it can read
Reads answer; writes propose. Everything in this list is a read, scoped to your account's permissions, and nothing here changes anything:
| Area | What it can look up |
|---|---|
| Status & sensors | How recently each sensor reported and whether it is stale, its QC flag counts and alert activity over the last 7 days, how many rules cover it, its field notes. Everything the app knows about one sensor — data source, expected frequency, timezone, staleness threshold, visibility flags, coordinates, folder, maintenance schedule, every variable with its label, unit, observed property and QC thresholds, its rating curves, and which maps and analytics pages include it. Your folders and what is filed where, and the editable fields of a sensor read off the app's own forms. |
| Alert rules | Every rule (static, moving-average, advanced/ML, compound) and every sensor + variable pair with no rule; one rule's complete current settings; every setting each alert kind has, with its allowed values. |
| Data & gaps | Actual readings for one variable on one sensor — count, lowest, highest and mean over a window, and a sample of the most recent rows with their QC grades. Where a variable is missing readings and what has already been filled. |
| QC & review | How QC is configured on a sensor (valid range, moving band, spike, flat-line, rate of change, gap, multivariate) and the good/suspect/fail counts of the last 7 days; the sensor's review periods, their status, and anything blocking approval. |
| Rating curves | Every stage–discharge curve on a sensor (type, coefficients, stage variable, discharge series, active or not) and every stage shift with its dates. |
| Exports | What the deployment can export, what each QC policy means, and whether a named sensor is ready to export or which variables still lack a standard property and unit — with the link to its export page. |
| Maps & analytics pages | Your maps (sensors, viewport, basemap, pin style, overlay layers, and whether each is private or published) and your named analytics pages (sensors and visibility). |
| Weather | Conditions now and a day-by-day forecast at a sensor's location (rain, chance of rain, high and low, wind), with recent days and hourly detail on request — it checks this before interpreting a rise or fall in your data. |
| Proposals | What this conversation has proposed and what became of each — waiting, applied, cancelled or expired. |
| The open map | Stations on the platform-wide open map — this platform's opted-in sensors and nine public catalogues — found by name or place, by whether they record stream stage, rainfall or both, by whether the last daily check saw data from them, and inside a box or a radius of a point. It can also move and mark the map itself while you are looking at it: ask it to show you the rain gauges near a town and the map flies there with them ringed, or fly a short tour from one view to the next when the answer is a sequence rather than a single picture. It can count what exists across all nine networks at once, which is the paragraph you usually want before any chart. |
| Rivers | Which stations sit upstream or downstream of another, along the actual river network rather than in a circle drawn around it. It walks across every catalogue at once, so it knows a state reservoir and a federal gauge are on the same water, and it can draw that river or its whole watershed on the map. It will also tell you how a station was matched to its reach — the provider's own crosswalk, which is a fact, or a snap to the nearest water, which is a likelihood, and it says how far it moved. |
| Outside readings | The current value at any station on those nine networks, and its recent history. Ask what a gauge reads now, or for the last two weeks of it, and the assistant fetches it and summarises what came back. Two limits worth knowing: it will not state a number it did not fetch in that conversation, so “I have not looked that up yet” is an answer you will sometimes get; and the Water Quality Portal publishes laboratory samples months apart rather than a series, so there is no line to plot and no current reading to give. |
| Drawing on the map | Lines, areas, circles and labels, for when the answer has a shape and no chart holds it — the stretch of creek you asked about, everything within five kilometres of a point, an area to gesture at while explaining. Rivers and watersheds come from real published geography rather than being drawn from memory. |
| Drawing | It can draw a plain SVG into the conversation — how sites sit along a reach, what a compound rule composes, a hand-plotted series — when a picture answers better than a paragraph. |
What it can propose, and the Confirm / Cancel flow
When you ask for a change, the assistant validates it against the real form and stores a proposal; the change happens only when you click Confirm. It can propose:
- alert rules created or changed (any field on any kind), paused or resumed, and — with no undo — deleted; a set of moving-average rules across several sensors at once;
- a new sensor — its display name, its data source and that source’s settings, the folder it is filed in and whether it is published. This is the step between finding a public gauge on the open map and being alerted on it, because an alert hangs off a sensor. Three parts of a sensor are deliberately not the assistant’s to give you: the permanent storage key is derived from the site code when you confirm (your display name can change later, that key never does); the variables appear by themselves when the first data arrives, and are labelled afterwards; and the upload credential cannot be shown in a conversation at all — confirming mints one, and a credential is displayable exactly once, on the sensor’s own page, so the assistant sends you there to press Rotate credential. A sensor the app fetches from does not need one;
- a sensor's Settings-page settings (public, on the map, on analytics, coordinates, field notes, folder), a sensor's identity and ingestion settings (site code, data source, expected frequency, timezone, staleness threshold and recipients, auth mode, maintenance schedule), and a variable's label, unit, observed property and whether it is plotted;
- a map or a named analytics page, created or changed — including its visibility, and it will say plainly when a change publishes data to anyone with the link;
- a rating curve or a stage shift; QC threshold changes (the stored series is re-graded when you confirm); gap fills and the retraction of fills (confirming a fill fabricates readings, marked synthetic and logged); review-period transitions (approving locks the span);
- field discharge measurements — the gaugings a rating is judged against. They publish no discharge; the assistant reads each one back with what the rating says it should have been and the total shift that would reconcile them, and it will repeat the numbers to you before drafting, because this is transcription from a field sheet;
- a CEDEN submission profile (the ProjectCode, AgencyCode, protocol and the coded columns) and the station row that registers one sensor in it under the StationCode CEDEN holds — it will ask you for those identifiers rather than deriving them, because a code built from a site code is a submission the data centre rejects, and nothing here can check one against CEDEN's register. The per-variable analyte mapping and the download itself stay on the sensor's CEDEN page, where a live preview shows what each row will look like;
- a custom export table — its layout, delimiter and the whole column list, each column naming where its value comes from. Built-in formats (CEDEN, WQX, USGS RDB, HEC-DSS) are standards and are not editable. Passing a new column list replaces the old one, and the assistant says so before it drafts one;
- rebuilding an advanced rule's ML model now instead of waiting for the nightly run — ask for it after a curve rebuild or a QC correction changed what the rule learned from, or when a badge reads Retrain failed. Several rules asked for together are one proposal and one Confirm.
Proposals dock above the ask box under Waiting for you, so one cannot scroll out of sight. Each card summarises the change and opens to its exact rows; Confirm (or Confirm N changes) applies it and Cancel discards it. With more than one waiting, Confirm all and Cancel all appear. A proposal is pending until you act, then applied or cancelled; one left for an hour expires and has to be asked for again. Your rights are checked again at confirm time, and the model has no part in what happens after you click. Only an account with read & edit on Assistant (or a superuser) sees proposals at all — with read alone the assistant answers but cannot draft.
There is no direct action. Nothing on the list above happens because you asked for it in words — every one of them waits for a Confirm. Retraining was the one exception until August 2026, on the argument that rebuilding a model changes no setting and no data. It was removed: a training run takes a slot on a shared worker and replaces the model a live rule is alerting on, which is a decision worth a click. If the assistant ever tells you something was done rather than drafted, it is wrong — check the Waiting for you dock.
Conversations
A conversation (session) is private to the account that started it — the transcript quotes your data back at you, so it carries your scope and is never shared. ☰ Chats opens the rail of your conversations with + New chat, a rename (✎) and a delete per row; several can be thinking at once and the rail says which still are. Clear chat deletes the current conversation and starts a new one — it asks first, and any proposals still waiting in it are cancelled with it. Deleting is real: the transcript is not kept.
Agent context and skills
Below the full-page assistant, Agent context is what you have given the assistant to work from. Everything here is sent with every question in its scope, so it is paid for on every turn — keep it to what changes an answer. On a group key the scope is the group, and instructions go into every member's conversations; on the deployment key it is yours. Editing needs read & edit on Assistant in the group (others can read it).
| Part | What it is |
|---|---|
| Standing instructions | How it should behave — tone, house style, standing orders ("We report depth in feet. Never propose changes to the tidal sites without saying the tide stage."). Up to 8,000 characters. Use this context switches the whole block on or off; Save keeps it. |
| Note — always true | A fact it should always know. Read as data, never as instructions. |
| Skill — a procedure to follow | Steps it follows when the situation arises. The When this skill applies summary is what it reads to decide whether the rest applies ("when asked to write a monthly report"), so write that line carefully. |
| Document | An uploaded PDF, Word (.docx), Excel (.xlsx), CSV, JSON or plain-text file, read into text — the text is kept (up to 40,000 characters), the file is not. |
| Image | PNG, JPEG, GIF or WebP, kept whole and shown to the model (on a provider that accepts images; the panel says if yours does not). |
Each item shows its kind, title, size and any extraction note. The ◉/○ button stops sending an item without deleting it (Stop sending this / Send this again); the bin deletes it. Add with Add a note or a skill (kind, title, when it applies, text → Add) or Upload a document or an image (file up to 12 MB, optional title → Upload); a context holds up to 40 items.
Geronimo IoT ships one skill, Environmental monitoring practice (marked shipped default): how to answer, what to verify before interpreting data, and when to push back. It is yours from the moment the panel is first opened — edit it, switch it off, delete it — and Restore the default skill brings it back if you change your mind.
LLM alerts read the same skills. An LLM alert has Include assistant skills and context on by default and a Which skills pick-list to pin a subset, so a skill you write here also shapes those rules — and editing it changes every rule that reads it.
How answers are rendered
The panel renders a subset of Markdown: headings, bold, italic, code, bullet and numbered lists, fenced code blocks, horizontal rules and pipe tables (tables scroll inside the drawer). Nothing else survives — images and raw HTML are dropped, and a link renders as its text with the URL in plain characters after it. Drawings appear inline as pictures.
Privacy and limits
- Recipient lists never reach the model. A rule's email and text recipients are encrypted at rest and are not included in anything the assistant reads; it is told how many recipients a rule has, not who.
- Scope is yours. Every lookup goes through the same permission checks as the pages, and a conversation is readable only by its owner.
- Sample caps. A data read returns at most 200 readings per call, and status, QC and alert counts look back 7 days — enough to reason over, not a month of 15-minute data. Ask for a specific variable and window when you want detail.
- Proposal cap. A proposal covering more than 100 rows is refused rather than truncated: a 300-row change is not reviewed, it is skimmed.
- Cost. Every question spends on the key named under the header, and everything in Agent context is re-sent on every turn. The group's key panel sets a rolling 30-day token budget; once it is spent the assistant answers with a budget message until the window moves on.
- Attachments. A picture, PDF or DOCX can be attached to a message; documents yield their text and their pictures. When the model behind the key cannot see images, the group's vision helper model describes them first, and the answer says so.
- The transcript, tool results and proposals are stored with the conversation; deleting the conversation deletes them.
Tips for good questions
- Say which sensor, variable and window: "depth at North Fork over the last three days", not "the data".
- Ask for the reason as well as the number — "is this rise rain?" makes it check the forecast before answering.
- Before a change, ask it to read first: "show me rule 12, then propose lowering its upper bound to 2.1." The proposal card shows the rows; read them before Confirm.
- Use folders as shorthand for groups of sensors, and name the rule or map exactly as it is titled.
- Put things that are always true — units you report in, sites that are off limits — into Standing instructions or a note rather than repeating them in every question.
- For a recurring judgement on a schedule, an LLM alert is the tool, not a daily question.