1. About this manual#

This is the complete operating manual for the Precision Intelligence Platform (PIP), the public-safety communications management system used by your communications center. It covers every screen, every record type, every report and every administrative control in the product.

How this manual is organised

• Sections 2–4 get you working: signing in, reading the interface, and understanding what your role is allowed to do.
• Section 5 is the one to learn properly. Every record screen in PIP behaves the same way, so once you can create, search, sort, edit, export and delete in one module, you can do it in all of them.
• Section 6 is the module reference — a card for every record type, listing its real fields, types and required entries. It is generated from the live application definitions, so it always matches the version you are running.
• Sections 7–14 cover the analytical and specialised areas: dashboards, the reports engine, training advancement (TIP), exposure scoring (CEDE), wellness, scheduling, accreditation and administration.
• Sections 15–19 are reference material: security and data handling, accessibility, troubleshooting, the glossary, and an API appendix for integrators.

Conventions used here

2. Getting started#

2.1 What you need

• A current version of Chrome, Edge, Firefox or Safari. PIP is a web application — there is nothing to install.
• Your agency code (for example vcc), your badge number, and your password.
• A network connection. PIP does not work offline; it reads and writes live center data on every screen.

2.2 Signing in

1. Open https://anima-app.cc in your browser. The sign-in card appears.
2. Enter your agency code. This is pre-filled for most centers.
3. Enter your badge number — this is your user name, not your name. Leading zeros matter: 0200801 is not the same as 200801.
4. Enter your password and choose Sign in.

PIP loads your role, your center's configuration and your navigation tree, then opens your default screen. What that default is depends on your role — a dispatcher lands on My Dashboard, a supervisor on the Calendar, a director on the Director Overview.

2.3 First sign-in and forced password change

When an administrator creates your account or resets your password, you are issued a temporary password. The first time you use it, PIP interrupts the sign-in and requires a new password before it will let you in. Choose a new password, confirm it, and you are signed in immediately — there is no second sign-in step.

The password rules are set by the platform: at least twelve characters, containing upper case, lower case, a digit and a symbol. PIP shows which rule failed rather than a generic rejection.

2.4 Changing your own password

Dispatchers have 🔑 Change Password at the bottom of their sidebar. Every other role can reach the same function from the administration area. You need your current password; changing it does not sign you out of the session you are in.

2.5 If you are locked out

There is no self-service password reset. Ask a supervisor, operations administrator or director to issue you a temporary one from 🔑 Password Admin — see 14.2 User administration. They cannot see your old password; nobody can. They can only replace it.

2.6 Your session

• Your session is held in your browser, so closing the tab and reopening PIP usually keeps you signed in.
• Access credentials are short-lived and are renewed automatically in the background. You will not be interrupted mid-task by an expiry, and you do not need to reload to "refresh" your session.
• If renewal fails — most often because your account was disabled or your password was reset while you were signed in — PIP returns you to the sign-in card. Work already saved is safe; anything typed into an open, unsaved form is not.
• Sign out is at the very bottom of the sidebar. On a phone it is inside the ☰ Menu panel. Use it on any shared or console workstation.

3. The interface#

Every screen in PIP uses the same three-part layout, so nothing you learn here has to be relearned later.

3.1 Layout

3.2 Navigating

• The sidebar is grouped under headings such as Shift, Performance and Scheduling. Select a heading to collapse or expand it; PIP remembers which sections you collapsed and restores them next time you sign in.
• Counts appear beside items that hold records, so you can see at a glance that QA Records holds 79 entries without opening it. Counts refresh when you add or remove a record.
• The address bar tracks your position as #/qa, #/staff and so on. That address is shareable — send a colleague the link and they land on the same screen, subject to their own permissions.
• Browser Back and Forward move through the screens you visited.

3.3 Themes and text size

Three themes are provided, and your choice is remembered on that device — including in this manual.

Text size offers normal, large and x-large. It scales the whole interface proportionally rather than only the body text, so tables and headings stay in step. This is independent of your browser's own zoom, which also works normally.

3.4 Print and Refresh

• Print produces a clean copy of the screen you are on: sidebar, toolbar and notifications are removed, the background is dropped to white and margins are normalised. Use your browser's Save as PDF destination to file a copy. The Light theme prints best.
• Refresh re-reads the current screen from the server. PIP caches data as you move around so that going back to a screen is instant; use Refresh when someone else has just changed something and you want to be certain you are looking at current figures.

3.5 On tablets and phones

Below roughly 950 pixels wide the sidebar moves above the content and the layout goes to a single column. Below 560 pixels — phone width — the navigation collapses behind a ☰ Menu button so the screen you asked for starts at the top of the display. Choosing a destination closes the menu automatically.

Wide record tables scroll sideways inside their own frame rather than forcing the whole page wide, so the toolbar and figures stay put while you swipe through columns.

3.6 Keyboard and assistive technology

While a dialog is open, Tab cycles within it and cannot escape to the page behind — so a keyboard user cannot get lost editing a record. Active navigation items, sort direction on columns and expanded or collapsed sections are all announced to screen readers.

4. Roles and permissions#

Everything you can see and do is decided by your role. Roles are assigned by an administrator and cannot be changed by the person holding them.

4.1 The five roles

4.2 What each role may do

Governance records means accreditation standards, committees, the consultant list, the department roster and leave & fiscal configuration. Supervisors may create and edit these but not delete them, so that a standard or a committee cannot be removed from the record by a single shift supervisor.

4.3 How "own records only" works

A dispatcher opening My QA Scores sees the same screen a supervisor sees, but containing only their own reviews. This filtering happens on the server, not in the browser: the records of other staff are never sent to a dispatcher's device, so they cannot be recovered by inspecting the page.

A record counts as yours when any of the following is true:

• You created it.
• Its staff, trainee, assigned to or staff ID field names you.
• On the roster, the record's name or badge is yours.

Four areas are deliberately shared with everyone, because they are library or board material rather than personal records: Wellness Resources, the Knowledge Center, the Department Calendar and the Shift Handoff Brief.

4.4 What a dispatcher can create and change

Dispatchers may create, edit and delete their own entries in exactly four places:

• 🎯 My Goals — development goals.
• 🗺 My Career Path — career milestones and aspirations.
• 💚 My Wellness History — daily self check-ins.
• 📋 My To-Do List — personal tasks.

Everywhere else — QA scores, attendance, certifications, training, reviews, exposure — a dispatcher has read access to their own records but cannot alter them. Those are supervisory records about them, and the integrity of the QA and attendance history depends on the subject not being able to edit it.

4.5 Roles are not the same as job functions

Do not confuse the five sign-in roles with the Function field on the roster, which records what somebody does — Communication Officer, Trainee, CTO, Supervisor, Relief Supervisor, Admin, OCC, Director, Consultant, Accreditation Specialist, Training Coordinator, QA Specialist, Operations Specialist, Part-Time. A person marked as a CTO on the roster still signs in with whatever role their account was given. Changing somebody's roster function does not change their access; only an administrator changing their role does that.

5. Working with records#

PIP holds over sixty different record types, and they all behave identically. Learn this section once and every module in Section 6 is already familiar.

5.1 Anatomy of a record screen

Open any record screen — QA Records, say — and you get, from top to bottom:

1. A figures strip: three or four headline numbers for that module, calculated across every record you can see, not just the page in front of you.
2. The module card, with its title, a one-line description, and a count reading 79 of 79 records. When you filter, the first number drops and tells you how much of the set you are looking at.
3. A search box, an Export CSV button and a + New button.
4. The table, with an Edit and Delete button on each row.

If your role cannot create records in that module, + New is not shown; if it cannot delete, the Delete buttons are not shown. The screen adapts rather than offering you buttons that will be refused.

5.2 Searching

Typing in the search box filters the table as you type. The search looks across every field of every record, not only the columns on display — so searching a CAD number finds the QA review that references it even though the CAD column is not shown. Matching is case-insensitive and matches anywhere within a value: fran finds Aretha Franklin.

Search is a filter, not a query language. There are no operators, quotes or wildcards; type the text you are looking for.

5.3 Sorting

Select any column heading to sort by it. Select the same heading again to reverse the direction. An arrow shows which column is in control and which way it runs. Sorting is per-module and is remembered while you stay signed in, so returning to a screen keeps the order you chose. Column headings are keyboard-operable — Tab to one and press Enter.

5.4 Creating a record

1. Choose + New. A dialog opens with the fields for that module. Focus is placed in the first field.
2. Complete the fields. Required ones are marked; see 5.5 for how each field type behaves.
3. Choose Save, or press Enter.

A confirmation appears briefly, the table redraws with your record in place, the figures strip recalculates and the sidebar count increases. To abandon a record, choose Cancel, press Esc, or select outside the dialog.

If something is missing

PIP validates before it saves. Missing required fields are outlined in red, a message names them at the top of the dialog, and the dialog stays open with everything you typed intact. The message persists until you fix it — it is not a notification that fades while you are reading it.

5.5 Field types

5.6 Why your lists look like your center

Shift names, position types, console layout and overtime categories are not fixed by the software. They are read from your agency configuration. If your center runs Alpha, Bravo, Charlie, Delta, that is what every shift picker offers; rename them and every picker follows. This is also why two centers running PIP can look quite different without any change to the software.

5.7 Editing a record

Choose Edit on the row. The same dialog opens with the current values filled in. Change what you need and save. PIP records who changed it and when.

When two people edit at once

If a colleague saved a change to the same record after you opened it, your save is stopped rather than silently overwriting theirs. You are told the record was changed by someone else and offered Reload record, which fetches the current version so you can reapply your change on top of theirs.

5.8 Deleting a record

Choose Delete and confirm. Deletion is immediate and there is no undo and no recycle bin. The deletion itself is recorded in the audit log with your badge and a timestamp, so the fact that a record existed and who removed it remains on the record even though its contents are gone.

5.9 Exporting to CSV

Export CSV downloads what you are currently looking at, which is the important detail: if a search filter is active, only the matching records are exported and the file name is marked -filtered so you cannot mistake a partial extract for the full set. Clear the search first if you want everything.

Files are named for the module and the date, contain a header row of the visible column labels, and use the line endings Excel expects. Yes/No fields export as Yes and No; multiple-choice fields export as a comma-separated list within the cell.

5.10 Very large modules

PIP loads record screens in pages and follows them automatically, so you normally see the complete set without doing anything. If a module is larger than PIP will load in one screen, a notice appears above the table saying so — take it seriously, because the figures strip and any export then describe only what was loaded. Narrow the set with a search before exporting, or use the reports engine, which aggregates server-side across everything.

5.11 What PIP records about every change

Each record carries the badge that created it, the badge that last changed it, and both timestamps. Every create, edit and delete is also written to the audit log. Nothing is anonymous, and this history is what makes PIP usable as an evidence source for accreditation.

6. Module reference#

Every record type in PIP, grouped as it appears in the sidebar. Each card gives the internal key, what the module is for, who can reach it, and — under Fields — the complete field list with types and required entries.

Badges: Own records a dispatcher sees their own entries · Dispatcher can edit a dispatcher may also create and change them · Governance supervisors may not delete these · In development present but unfinished.

7. Dashboards#

Dashboards are read-only summaries calculated on the server across everything you are permitted to see. They are always current as at the moment you opened them; the generation time is shown so you know how old the figures on your screen are.

7.1 Center Overview Ops Admin

The operational picture: active staff, trainees and CTOs on the roster; the QA average and how many reviews fell below target; how many shifts breached minimum staffing; overtime hours; and coverage verifications ready against short.

Two of these figures are judged against your configured standards rather than fixed numbers. The QA target and the minimum staffing level both come from agency configuration, and the screen names the threshold it applied — so a center targeting 95% is not measured against some other center's 90%.

7.2 Director Overview Director

The same underlying figures presented for executive use, alongside open deficiencies, readiness and accreditation compliance. This is the screen to open before a governing-body meeting.

7.3 Center Health Index Director Consultant

A single composite score out of 100, with a band, built from six equally weighted components. The screen shows each component's own score and a bar, so a poor composite can immediately be traced to its cause.

Bands: Green 85 and above · Yellow 70–84 · Amber 55–69 · Red below 55.

7.4 My Dashboard Comms Officer

A dispatcher's personal summary: their QA average and trend, attendance position, certifications approaching expiry, training status, open goals and recent wellness check-ins. Every figure is their own. My PSC File alongside it presents their complete personnel record in one place — useful ahead of a review conversation.

7.5 Event Dashboard

Tracks planned and active events with their status and staffing implications, so an event's demands on the center are visible before it arrives.

7.6 Demo Dashboard Director Consultant

A presentation view for demonstrations and briefings, showing the platform's capability across modules without requiring the presenter to navigate between screens.

8. Reports and analysis#

8.1 Reports Engine

Fifteen reports are provided. Choose one and PIP aggregates it on the server across every record — not just what a screen had loaded — then returns a table you can read on screen or export. Each renders a chart above its table.

Reports are the right tool whenever the answer must cover everything — a governing-body figure, an accreditation submission, a staffing case. A filtered CSV export from a record screen answers a narrower question and should not be presented as a center total.

8.2 Analytics & Graphs

📈 Analytics presents the center visually: twelve months of trend, current composition and per-officer ranking, over five tabs — Performance, Staffing & coverage, Wellness & exposure, Training and Call quality.

Charts to expect: QA average by month against your configured target, review volume, call mix, coverage outcome by month, roster composition, overtime outcome, wellness risk bands, exposure by officer, the TIP gate funnel and certification currency.

The whole page comes from one server-side aggregation, so it stays quick regardless of how much history the center holds.

8.3 Report Builder

For questions the nine standard reports do not answer. Choose a module, choose the fields you want, group the output, and export the result. Use it for one-off requests rather than recurring reporting — if you build the same thing every month, that is a sign it should become a standard report.

8.4 Equity & Exposure hub

Brings distribution and exposure together: how work, overtime and traumatic calls are spread across the floor. Equity questions and exposure questions are usually the same question asked twice, which is why they share a screen.

8.5 Report Archive and Pooled Reports

• 📁 Report Archive — filed reports, retained and searchable. The record of what was reported and when, which matters when a figure is later questioned.
• 📊 Pooled Reports — data combined across shifts or periods for center-level and multi-agency reporting. Each pooled report records which shifts it included, so its scope is never ambiguous.
• Submit PIP Report — files a new structured report into the system.

9. TIP — Training Intelligence Platform#

TIP decides, consistently and on the record, whether a trainee may advance to the next phase. It replaces a judgement call with five explicit conditions, evaluated the same way for every trainee.

9.1 The five advancement gates

A trainee may advance only when all five conditions pass. The TIP screen shows each condition and its state, so a trainee who cannot advance can be told exactly why.

9.2 Configuring phases Supervisor Consultant

⚙️ TIP Agency Configuration defines each phase: its advancement threshold, minimum hours, whether a DOR signoff is required, which certifications are applicability-gated, and which disciplines the phase covers. This is where your training program's standards live.

9.3 "Applicability-gated" and other terms

• Applicability-gated certification — a certification required only of trainees it applies to. A trainee not working fire dispatch is not held back by a fire radio certification.
• DOR — Daily Observation Report. Where a phase requires it, an advancement needs a documented observation signoff, not only numbers.
• Layer and discipline — which part of the program and which operational discipline the phase belongs to, so multi-discipline centers can run parallel paths.
• Task scope — what the trainee is being held accountable for in this phase.

9.4 Using TIP day to day

A CTO or training coordinator updates the trainee's score and hours as the phase progresses, marks certifications and any DOR signoff, and keeps the task scope current. The gate display then answers "is this trainee ready?" without a meeting. The TIP advancement gates report gives the same answer for every trainee at once, and the training component of the health index is driven by it.

10. CEDE and exposure#

CEDE — Cumulative Exposure & Decision Environment addresses something traditional metrics miss: the accumulated cost of the calls a dispatcher takes and the decisions they carry. A dispatcher can be performing well on every conventional measure while accumulating exposure that needs attention.

10.1 How it is built

1. Significant calls are recorded per officer in the PST Call Exposure Log. This is the input, and the quality of everything downstream depends on it being kept.
2. CEDE combines that history into an exposure score and a decision load for a period.
3. Those produce a ROC score and a risk band, alongside recovery days since the last significant exposure.

Dispatchers see their own figure as 🔄 My ROC Score, next to their own exposure log. Supervisors and above see the center picture.

10.2 Using it responsibly

Recovery days matter as much as the score. A high score with a long recovery interval is a different situation from the same score accumulated across three consecutive shifts.

11. Wellness#

Wellness runs on four screens that deliberately separate what an individual reports from what management sees.

Amber and red risk counts reduce the wellness component of the center health index, so a deteriorating floor shows up in the executive summary rather than staying buried.

The whole wellness area can be switched off for centers that handle it outside PIP — see the Wellness module feature flag in agency configuration.

12. Scheduling and coverage#

Scheduling spans several screens because building a schedule, working it, verifying it and approving it are different jobs done by different people.

12.1 Building

• Schedule Builder — construct a schedule for a period.
• Roster Builder — assemble who works which rotation.
• Floor Schedule — the schedule as worked, by position and day. A dispatcher sees their own line here as My Schedule.

12.2 Supervisor Schedule Ops Admin Consultant

Supervisory coverage should be as predictable as floor staffing. This screen shows every supervisor rotation for a month on one calendar, each supervisor in their own colour, with a rotation spanning several days drawn as a single continuous bar.

Its real purpose is the opposite of showing coverage — it shows where coverage stops. Any day of the month with no supervisor rotation is outlined in red, marked with a dot, counted as an uncovered day, and listed explicitly above the calendar. A center can then close the gap by adding a rotation or extending an existing one before the day arrives rather than discovering it on the day.

A month for which nothing has been scheduled yet is treated differently: it is reported as not yet scheduled rather than as a month of failures, because an unplanned future period is expected. Red marking is reserved for a hole inside a month that is otherwise covered.

The figures strip reports rotations on file, how many supervisors are in the rotation, days covered out of days in the month, and the uncovered count. Beneath the calendar, current and upcoming rotations are listed, and the usual record table lets you add or amend one.

12.3 Schedule Approvals Ops Admin Consultant

Staffing plans are reviewed before they are published. A supervisor drafts a schedule and submits it; it then appears in this queue for an operations administrator to approve or return.

1. View opens the floor schedule for that shift so you can inspect the actual plan before deciding, rather than approving a title.
2. Approve publishes it. A comment is optional.
3. Return sends it back. A comment is required — a bare rejection tells the supervisor nothing.

Either decision stamps your name as reviewer, records your comment, and writes an entry to the audit log. Decisions already made are listed below the queue with their outcome, reviewer and comment.

12.4 Coverage verification

Each coverage record confirms whether a shift met minimum staffing, measured against the minimum staffing figure in your agency configuration. This is one of the most consequential records in PIP: the ready-versus-short ratio is the staffing component of the health index, the readiness figure on the director overview, and the evidence behind any staffing case you make. A center that does not keep coverage verifications cannot demonstrate a staffing problem it knows it has.

12.5 Leave and overtime

• Leave Calendar — requested, approved and taken leave. Dispatchers see their own only.
• OT Call List — who was offered overtime, in what order, and who accepted or declined. This is what makes overtime distribution defensible when it is challenged.
• Standby Roster — callback and short-notice coverage.
• Leave & Fiscal Config — accrual rules, leave categories and the fiscal year that balances are calculated against. Governance

Paid-leave and extended-illness balances live on each person's roster record, and the categories offered when recording leave come from your configuration.

12.6 Calendar

The 📅 Calendar presents center activity by month — department dates, leave, training, incidents, committee meetings and shift entries in one view, each source in its own colour. Anything spanning several days is drawn as one continuous bar rather than repeated entries, today is outlined, and weekends are shaded. The legend counts each source across the whole data set.

Move between months with ‹ Previous, Today and Next ›. On a phone the month grid becomes a single-column day list so it stays readable. The Department Calendar holds center-wide dates and is visible to everyone including dispatchers.

13. Accreditation and governance#

13.1 Accreditation

Each record is a standard and its compliance state. The share marked compliant is the accreditation component of the health index, and these records — with their edit history — are what an assessor asks to see. Keep the state current as evidence is gathered rather than reconstructing it before an assessment.

13.2 Deficiencies

Identified gaps and their remediation status. Open deficiencies surface on the director overview and in the health index, so an unaddressed deficiency does not quietly persist.

13.3 Executive material Director Consultant

• 🏛 Executive Readiness — the consolidated readiness position for an executive audience.
• 📝 Narrative Generator — turns center data into written narrative for reports and briefings. Always read and edit what it produces; it assembles from your data but cannot know the context behind a figure.
• 🏛 Reclassification Evidence — assembles the documentation supporting a position reclassification case.
• 🏛 Committees — membership, remit and activity of standing committees. Governance

14. Administration#

14.1 Agency configuration Ops Admin Director Consultant

This screen shapes the whole application for your center. Supervisors and dispatchers can view it; only the roles above may change it. Every setting is scoped to your agency alone.

The four list settings are entered as comma-separated values. Choose Save configuration and the change takes effect across the center immediately.

14.2 User administration Ops Admin Director Consultant

🔑 Password Admin lists every account in your agency with its badge, name and role.

Removing a user does not remove them from the roster. The roster entry is the personnel record; mark them Separated there rather than deleting it.

14.3 Audit log Supervisor and above

Every create, edit and delete across your agency, newest first, showing what changed, which record, which badge and when. It is written automatically, cannot be edited or cleared from the interface, and is exportable for an assessor or an investigation.

Use it to answer "who changed this and when", to confirm a deletion, and as accreditation evidence that records are controlled. The log covers your agency only.

14.4 Trash and recovery

Deleting a record does not destroy it. It is marked, dated, removed from its module and placed in 🗑 Trash, where it stays recoverable for 30 days.

The trash lists what each record was, who deleted it, when, and the date it will be purged. A dispatcher sees only their own deletions. Deletion and restoration are both written to the audit log.

14.5 Demo Controls Consultant

Rebuilds the demonstration data set for a tenant. Available to consultants only.

14.6 In-application guides

📖 Program Guide and ⚡ Quick Reference are built into the sidebar alongside this manual — the guide for program concepts, the quick reference for the tasks a supervisor performs most. 📚 PKC — Knowledge Center holds your center's own institutional knowledge and is maintained by your staff, not by the software.

15. Data, privacy and security#

15.1 Your center's data is isolated

PIP is multi-tenant: several agencies run on the same platform, each seeing only its own data. The separation is enforced on the server from the identity you signed in with, not from anything your browser sends. A request cannot reach another agency's records by asking for them, and the same badge number existing in two agencies produces two entirely separate identities.

Records, configuration, users and the audit log are all partitioned this way.

15.2 Sign-in and sessions

• Passwords are held by a managed identity service, not by PIP, and are never visible to anyone — including administrators, who can only replace them.
• Password rules: at least twelve characters with upper case, lower case, a digit and a symbol.
• Access credentials are short-lived and renewed in the background, limiting the value of a credential captured from a browser.
• Every request is authenticated. There is no anonymous access to any center data.

15.3 In transit and at rest

• All traffic is encrypted in transit; the application is served only over HTTPS.
• Stored data is encrypted at rest, with point-in-time recovery enabled so the database can be restored to an earlier moment.
• Center data is not stored on your device. Only your session, your theme and which sidebar sections you collapsed are held locally.

15.4 Accountability

Every record carries who created it, who last changed it, and when. Every change is written to the audit log. Deletions are logged even though the content is gone. This is deliberate: a system used for QA, discipline-adjacent records and accreditation evidence has to be able to show its own history.

15.5 What is expected of you

• Sign out on shared consoles. Records created in your session are attributed to your badge.
• Do not share credentials. If two people need access, they need two accounts — otherwise the audit log becomes meaningless.
• Ask for an immediate reset if you think your password is known to someone else.
• Treat exports as sensitive. A CSV of the roster or of QA reviews carries personal information and, once downloaded, is outside every control PIP applies.

16. Accessibility#

PIP is built to be operated without a mouse and to work with assistive technology.

• Skip to page content is the first keyboard stop on every screen, so you do not have to tab through a long sidebar to reach the working area.
• Everything interactive is reachable and operable by keyboard, including sidebar section headings and sortable column headers. The focused control always shows a visible outline.
• Dialogs trap focus while open, so Tab cycles within the form and cannot stray behind it. Esc closes and returns focus to the control you opened it from.
• Screen readers are told which navigation item is current, whether a section is expanded, and which column a table is sorted by and in which direction.
• Three themes and three text sizes address contrast and low-vision needs; Midnight gives maximum contrast, Light suits bright rooms and print.
• The layout reflows to tablet and phone widths without loss of function, and wide tables scroll within their own frame rather than forcing the page sideways.

17. Troubleshooting#

17.1 Common situations

17.2 Reporting a problem

Include: your badge and agency code, the screen — the #/... part of the address is ideal — what you did, what happened, what you expected, the exact wording of any message, the build stamp from the foot of the sidebar, and your browser and version.

18. Glossary#

19. Appendix — API reference#

For integrators only. Day-to-day users do not need this section. The same interface the application uses is available directly, so center data can be integrated with other systems.

19.1 Authentication

Sign in to obtain tokens, then send the ID token as a bearer credential on every subsequent request. The tenant is taken from a claim inside the token — it is never read from the request body, which is what makes cross-tenant access impossible.

POST /api/auth/login
{ "agency": "vcc", "badge": "0201401", "password": "…" }
→ { idToken, accessToken, refreshToken, user: { badge, name, role, … } }

GET  /api/modules/qa
Authorization: Bearer <idToken>

19.2 Records

19.3 Pagination

List responses carry complete: true when the whole set was returned. Otherwise follow nextCursor until it is absent:

GET /api/modules/qa
→ { items: [ … ], count: 500, complete: false, nextCursor: "eyJ…" }

GET /api/modules/qa?cursor=eyJ…
→ { items: [ … ], count: 259, complete: true }

19.4 Concurrency

Send the updatedAt value you read as version on update. If the record has changed since, the write is refused with 409 and code VersionConflict — re-read and reapply. Omitting version performs an unconditional write, so include it wherever a lost update matters.

19.5 Response codes

19.6 Integration guidance

• Validation is enforced server-side against the same module definitions the interface uses, so a client cannot write a record the interface would reject.
• The role permission model applies identically over the API. A dispatcher's credentials return only that dispatcher's records.
• Writes are audited exactly as interface changes are. An integration's activity is attributed to the account it authenticates as — give integrations their own account rather than borrowing a person's.
• Refresh credentials rather than re-authenticating on every call.

Document information#