# RSI AI — Public-service workflow blueprint

**Version 1.2 · 8 October 2026 · Melbourne, Australia**  
Companion to the interactive public-service scenario at https://rsiagent.app/#public-service

## 1. Purpose and current status

Help an officer move from a resident’s call to evidence review, a structured handover, a reviewable processing proposal and a weekly task overview, within the organisation’s approved tools and work allowance.

The website is a deterministic, browser-only demonstration using invented records. It does not capture audio, upload documents, call a model, connect to Copilot or Salesforce, operate a computer, or submit government records. Its existing usage ledger and adaptive routing forecasts use synthetic token estimates, not measured provider usage or a savings claim. The production architecture below is a proposal for an approved pilot, not an existing integration, customer deployment or accreditation.

RSI AI is an independent early-stage Melbourne venture. A public-sector pilot would require the participating organisation to authorise the purpose, information, access, products and actions. The existing public whitepaper remains a separate document; this blueprint adds the public-service scenario.

## 2. The five-stage experience

| Stage | Officer experience | Proposed orchestration | Reviewable output |
| --- | --- | --- | --- |
| Call | Read a provisional transcript and important details as the call develops. | Extract facts on new final segments; check a potential inconsistency only when relevant. Retrieve approved procedures, not unrelated case history. | Timestamped facts, contact preferences, outstanding questions and source references. |
| Documents | Select authorised evidence and inspect highlighted passages. | Check access, extract text, apply approved redaction and summarise minimum-necessary passages. | Document/page/span citations; clearly separated statements and unresolved differences. |
| Handover | Choose a template and add an officer note. | Render the current case state at wrap-up; retain missing facts and uncertainty. | An editable draft, revision number and explicit officer review. |
| Processing | Inspect the proposed CRM field changes and permitted route. | Prefer a narrowly scoped API action; recheck permission and case version at execution. | An approved clerical patch and an auditable result. New procedure ideas stay as draft skills. |
| Weekly | Switch between the officer’s work queue and an authorised team aggregate. | Query the task/event ledger; optionally draft a narrative against those exact counts. | Completed, pending and blocked work with traceable task rows. |

The demo has three presets: routine follow-up, conflicting evidence and restricted access. The conflict case keeps a reported upload date separate from a receipt date, then exposes a genuine difference between a caller-reported move date and the submitted form. It asks for clarification rather than inferring deception. The restricted case excludes inaccessible records and defers optional work when its smaller sample allowance is exhausted.

### Implemented native workflow workspace

The public showcase now combines an interactive intervention map with the functional officer workbench. The frontend uses **React 19.3.0 and React DOM 19.3.0**, **React Flow (`@xyflow/react`) 12.12.0**, and **Motion 14.0.0**, with the `motion/mini` entry point for short Web Animations API transitions. These versions are recorded as implementation choices. [9][10][11][12]

The existing static HTML and esbuild pipeline remain the delivery foundation. A separate JavaScript island loads when the public-service section approaches the viewport or the visitor opens it. React mounts the graph and workspace controls alongside the prepared officer panel. This follows React's supported incremental integration pattern. [13]

| Implemented layer | Behaviour in the public sample |
| --- | --- |
| Shared state | The existing deterministic controller publishes a cached immutable snapshot through `useSyncExternalStore`. Graph inspection, allowance figures, current stage and officer controls read the same case state. The snapshot retains its identity until publication. [14] |
| Intervention map | A pure presentation adapter derives **12 nodes and 14 directed edges** for the call, essential facts, context checks, evidence, conditional comparison, handover, officer review, field changes, local CRM result, skill proposal and weekly workload. It introduces no task execution or permission changes. |
| Desktop workbench | A pannable, zoomable graph sits beside the selected step's explanation, source links and working call, document, handover, processing or weekly panel. Zoom, fit and focus controls make the graph navigable; measured canvas dimensions determine its initial fit. |
| Mobile presentation | The default Steps view exposes the same selectable workflow stages and officer controls in a vertical layout. Visitors can also choose Flow. |
| Keyboard and focus | Nodes support keyboard inspection and spatial navigation. Commands opens through its button or Cmd/Ctrl+K. Focus mode expands the existing workspace, manages focus and makes surrounding page content inert until the visitor exits. React Flow supplies the underlying keyboard and viewport primitives. [15][16] |
| Motion and trace | Short edge pulses show newly recorded sample work; the execution trace exposes estimated and charged fixture events. Reduced-motion preferences, the site's pause control, hidden-page state and whole-workspace visibility govern motion and playback. |
| Review boundary | Selecting a node or changing a stage changes the view without charging model work, granting permission or approving a document. The existing explicit acknowledgement, approval and apply actions retain their revision checks. Officer-note typing preserves the textarea while immediately invalidating dependent drafts and reviews. |

The map visualises the local simulation. Its agent labels describe prepared extraction, comparison and drafting steps; they do not represent connected model workers. The CRM operation changes only the synthetic browser record, and the skill output remains a reviewable proposal. A real deployment would require the authenticated backend, provider usage reconciliation, durable events, access checks and approved adapters described below. Browser state and animation are presentation mechanisms, not a production authorisation boundary.

## 3. Deployment boundary and product fit

“Copilot” must be resolved to the specific licensed product before estimating capacity. Copilot Studio uses credits with feature-dependent charging; some reasoning also has token-based metering. Qualifying employee scenarios can be included under particular licensing conditions. Copilot Cowork separately documents reasoning-effort controls. Neither fact establishes a universal raw-token allowance or effort-setting API for every Copilot surface. Map the policy router only to supported, approved controls. [1][2]

Use the agency’s approved hosting, identity, model endpoints, retention and logging configuration. Do not send case data to the public RSI showcase or an unapproved external model. An Australian location alone does not establish that every model, log, support process and subprocessor keeps data in that location; validate the complete approved service path.

Microsoft’s Salesforce search connector and its Salesforce action connector serve different purposes. Search indexing requires particular care with field-level permissions and permission refresh; API write access must be separately configured. The proposed adapter checks the current user’s record, object and field permissions for the requested operation, rather than treating a search result as write authorisation. [3][4]

## 4. Proposed technical components

### Approved ingress and a shared case state

An authorised telephony integration supplies transcription events. Preserve provisional/final status, speaker labels, timestamps and correction history. Azure Speech documents real-time transcription and diarization, including provisional unknown-speaker labels; speaker separation is not identity verification. Capture and retention must follow the organisation’s approved call-recording process. [5]

Keep one structured case state. Specialist workers receive the facts and evidence required for their task instead of replaying the entire conversation to every worker. A transcript or document is evidence, never an instruction to grant access, install a skill or run a tool.

Proposed server-side contracts:

```ts
type EvidenceRef = {
  sourceId: string;
  sourceVersion: string;
  page?: number;
  start?: number;
  end?: number;
  timestampMs?: number;
};

type CaseFact = {
  key: string;
  value: string;
  status: "reported" | "verified" | "unresolved";
  evidence: EvidenceRef[];
};

type ProposedPatch = {
  caseId: string;
  expectedCaseVersion: string;
  allowedAction: string;
  changes: Array<{ field: string; before: unknown; after: unknown }>;
  evidence: EvidenceRef[];
  approvalDigest: string;
  idempotencyKey: string;
};
```

The approved backend, not browser-supplied state, must establish identity, permissions, record versions and approval validity. The public demo’s local review controls illustrate this sequence; they are not a production security boundary.

### An event router and a real usage ledger

Use deterministic routing for stage changes and known triggers. Model work is reserved for language extraction, supported comparison and drafting. Ordinary code performs permissions checks, deduplication, arithmetic, task counts, template structure and rule enforcement.

```text
on case event:
  authenticate and authorise the case operation
  validate the event and deduplicate by event ID
  update the versioned case state
  invalidate dependent drafts and approvals
  identify required and optional work
  reserve capacity for remaining essential capture and handover
  execute only approved tasks that fit the applicable limits
  reconcile estimated usage with provider-reported usage
  retain deferred tasks and the reason for deferral
```

Track input/output tokens where the chosen service reports them, plus the provider’s own credits or billing units, model, request ID, latency, retries, tool calls, transcription/OCR usage and applicable prices. Keep estimates and observed charges in separate fields. Token avoidance is not automatically an equal reduction in a subscription bill.

A production limiter must account for concurrent in-flight requests, worst-case output, retries and overhead that may not be visible in an officer’s text. Reserve before dispatch and reconcile after completion. Budget exhaustion should stop optional calls, keep the evidence accessible and produce a deterministic handover with unknown fields clearly marked. Do not silently remove important facts to meet a target.

### Adaptive priority and model routing

The v1.5 demonstration adds a pure routing planner, `deriveRoutingPlan({ view, graph, policy, catalog, history })`. It derives **12 node-level routes**: five types of language-model work, four ordinary rule/aggregation steps and three human review gates. A route is a proposal; it does not start an agent, change the prepared workflow or call a provider. A model-work category can contain several future work items, such as remaining call segments or permitted documents, so five categories does not mean five API requests.

**Scheduling priority, task complexity and consequence are separate inputs.** An urgent call can require a short extraction; a non-urgent skill proposal can require complex reasoning. Neither urgency nor a stronger model grants permission to modify a record.

| Proposed language work | Priority | Complexity / consequence in this sample | Routing purpose |
| --- | --- | --- | --- |
| Essential call facts | P0 | Simple / moderate | Protect timely capture of required facts; propose a scoped compact-model worker where its synthetic acceptance profile passes. |
| Permitted document summaries | P1 | Medium / moderate | Summarise selected accessible documents only; inaccessible bodies are excluded before routing. |
| Cross-source comparison | P1, when a comparison is pending | Complex / high | Allocate a suitable review candidate for contradictions and evidence relationships; an unresolved difference remains unresolved. |
| Source-linked handover | P1 | Medium / high | Reserve essential drafting capacity and retain exact-version officer review. |
| Reusable skill proposal | P2 | Complex / moderate | Prepare an optional improvement for later separate approval; defer it when a passing route cannot fit. |

The prepared transcript, permission/budget arithmetic, exact local field application and weekly counts use ordinary code with **zero proposed model calls**. Handover approval, field acknowledgement and skill approval remain explicit human gates. The planner does not delegate permission checks, arithmetic or approval authority to a language model.

#### Policy before model preference

The public catalog records official model identities and supported first-party API features. The planner separately requires an explicit `policy.allowlist`; an absent or empty list allows no models. The demonstration's allowlist permits local planning only and does not represent an agency-approved service list. The planner can also exclude a provider marked unavailable in the scenario, deny a task, disable external model routing, or require a processing region. Catalog entries have no regional endpoint verified for this project; when a particular region is required, unknown compatibility rejects that route.

Only after these gates does the planner apply the selected objective:

- **Balanced:** balance the synthetic acceptance profile and estimated future work.
- **Efficiency:** choose the smallest eligible estimate while retaining the acceptance floor.
- **Responsiveness:** favour the responsive synthetic role profile within the same permission, capability, acceptance and allowance gates.

`maxEffort` is an independent policy ceiling. A candidate whose task profile requires an unsupported effort level or a level above that ceiling is excluded. The planner does not silently raise the ceiling or lower the acceptance floor to complete more work. The displayed acceptance scores, work multipliers and responsiveness units are **invented demonstration profiles**, not a benchmark, actual confidence assessment, latency measurement or claim that one provider outperforms another. Both compact-model candidates use the same synthetic profile; their deterministic tie-break is not a comparative performance claim.

#### Current catalog snapshot

Official sources checked 8 October 2026 confirm the following public API models. The date column records the provider's release date, not an asserted exact Melbourne release time. Haiku's official name is **Claude Haiku 5.5**. [17][18][19][20][21]

| Model | First-party API ID | Provider release date | Supported effort / default | Proposed sample role |
| --- | --- | --- | --- | --- |
| Claude Haiku 5.5 | `claude-haiku-5-5` | 7 October 2026 | low, medium, high, xhigh, max / medium | Scoped high-volume language work |
| GPT-6 Luna | `gpt-6-luna` | 22 September 2026 | none, low, medium, high, xhigh, max / medium | Alternative for scoped high-volume work |
| Claude Sonnet 5.5 | `claude-sonnet-5-5` | 28 September 2026 | low, medium, high, xhigh, max / high | Cross-source synthesis and escalation candidate |

Luna's API model card documents text, image input, structured outputs and function calling; the Responses API is the documented path for its built-in tools. The Claude model and structured-output documentation confirms text/image input, text output, tool use and structured-output support for Haiku 5.5 and Sonnet 5.5 on the first-party API. Check the exact hosting path before assuming feature parity. [18][19][21][22]

Effort is a behaviour control rather than a hard token budget. Claude's current guidance warns that low-effort Haiku can omit checks in long agent prompts. Use bounded, well-specified workers, validate their outputs and leave room for thinking within the output cap. A future provider adapter must map the supported effort and thinking controls separately for each model; an identically named effort level is not a calibrated cross-provider compute unit. [23]

The catalog retains dated first-party Standard prices and source links for engineering review. Haiku's lower price tier includes prompts up to 100,000 tokens; its higher tier applies above that length. Luna's long-context rates apply above 272,000 input tokens to the full request. These thresholds, different tokenizers, output usage, cache eligibility, retries, tools and hosting modifiers prevent a universal flat-token comparison. The routing demonstration does not calculate provider bills from its invented profiles or claim measured savings. [19][24][25]

#### One shared allowance, bounded recovery and honest history

Completed fixture charges remain authoritative. Future route estimates and any bounded retry reservation share the existing case allowance. The planner reports `spent`, `forecastTokens`, `retryReservedTokens`, `requiredReservedTokens`, `projectedTotal`, `available` and `withinAllowance`. Required reservations describe the protected essential portion of the forecast; they are not added a second time. The projected total is:

```text
existing fixture charges + future route estimates + reserved retry capacity
```

Essential capture and handover receive capacity before optional work. Selecting an objective does not create a second budget, restore spent capacity or reinterpret a synthetic token as a Copilot credit. If a policy tightens the limit below already recorded work, keep those charges visible rather than rewriting history to make the total fit.

A synthetic validator-failure control illustrates recovery. The planner can propose **at most one additional, higher-profile attempt per language-work category**, only when that model remains allowlisted, supported, within the effort ceiling and affordable. The initial failed proposal remains in the forecast. If no eligible retry fits, stop for officer review or defer; a retry proposal does not establish that the output passed validation. In production, validation should check schema, required fields, source coverage and contradictory evidence. Model self-reported confidence is insufficient to approve a consequential operation.

Policy changes replan pending work. They do not retrospectively relabel completed work with the newly preferred model. The optional local history retains the proposal present before a prepared event, its policy identity and revision. Events already complete when the planner first mounts have no invented model attribution. This is **sample proposal history, not a provider execution log**. The UI can expose the current route on a node, explain rejection or fallback, and export the serialisable plan for inspection without running it.

#### Promotion path for a real router

A production router needs representative, permitted evaluation cases for each task type, including missing evidence, conflicting dates, denied access and provider failures. Compare successful task completion, important-fact recall, correction rate and officer review effort alongside actual latency, retries and provider-reported usage. Evaluate each model/effort pair against the same acceptance criteria; price or a launch announcement alone is insufficient evidence to promote a model.

Keep a versioned model registry and routing policy. Validate model IDs, capabilities, endpoint region, current availability and cost rules; then shadow-test or canary a candidate within the approved scope before promotion. Retain rollback to the last approved configuration. Runtime dispatch needs bounded retries, circuit breakers, rate/concurrency limits, reservation reconciliation and idempotent tool execution. A failed provider call must not cause duplicate CRM writes or bypass the exact-diff approval. These are proposed backend requirements and have not been implemented as live services in the showcase.

### Evidence review and redaction

Check permission before retrieving a body and again before a sensitive action. Use a document ID allowlist tied to the case and officer. Parse text/OCR inside the approved boundary; retain offsets so highlights point to the exact rendered passage. Highlighting a sentence must not change its meaning or conceal contradictory evidence.

The demo masks a closed set of fictional identifiers. A production redaction component needs document-type rules, validated detectors, exception handling and an officer inspection path. Keep any identity mapping separately protected. OVIC explains that linked or distinctive details can re-identify de-identified records: removing names is not a guarantee of anonymity or permission to export the remaining content. [7]

### Handover and processing

Version templates and require a defined owner. A handover should contain purpose, verified/reported facts, officer notes, unresolved questions, next action, owner, due date and evidence. Changing a call fact, selected document, note or template invalidates the dependent review. Exported drafts must retain their review status and uncertainty.

A permitted write follows: propose a narrow field diff, review it, bind approval to that exact diff and case version, re-authorise immediately before execution, apply idempotently, then reconcile the actual CRM result. A version mismatch returns the proposal for fresh review. Do not label a transport success as a completed business task until the expected record state is confirmed.

Victorian guidance requires staff accountability, verification and appropriate records, and prohibits using GenAI for government decisions and consequential administrative assessments/actions. An officer clicking “approve” does not itself authorise a prohibited use. Keep any pilot assistance and clerical automation within the agency’s confirmed permitted purpose. [6]

### Computer use and reusable skills

Use a supported connector/API first. A later legacy-interface route would need its own approval, dedicated environment, appropriate user/scoped credentials, bounded actions, observation, cancellation and recovery. Copilot Studio computer use has specific machine/orchestration requirements; default maker credentials can expose the maker’s access to other users. Review credential and navigation controls explicitly. [8]

A skill is a versioned procedure with an owner, triggers, required evidence, permitted tools, expected outputs and tests. Suggested lifecycle:

1. Draft from a reviewed procedure or observed pattern, with sensitive case content removed.
2. Replay against synthetic normal, missing-data, conflict and denied-access cases.
3. Review by the designated process owner; approve the exact version and scope.
4. Publish to the approved registry; retain rollback and expiry information.
5. Monitor corrections and retire a skill when the source procedure changes.

Do not let a model silently learn policy from a resident’s record, change a procedure, expand permissions or promote its own skill. In the public demo, the final skill state is only a reviewed sandbox proposal.

### Weekly work overview

Use the event ledger as the source of counts. Define completion, reopened work, pending review, blocked access and due dates consistently; retain event timestamps and the reporting timezone. A team view requires an appropriate role and aggregate scope. Keep customer details and unrelated staff activity out of the shared summary. Do not infer employee performance from transcript sentiment or conversation content.

The demo updates its dashboard as the visitor advances and reviews the sample work. It has no weekly background schedule. Production scheduled reports would be a separate authorised flow with its own access, delivery destination and product-usage assessment.

## 5. A practical pilot sequence

| Gate | Scope | Evidence to proceed |
| --- | --- | --- |
| Discovery | Identify the product/licence, approved purpose, information classes, telephony path, templates and process owner. | Agreed scope and approved data/action boundaries; a baseline of current work. |
| Synthetic sandbox | Read-only fixtures and denied-access cases; no resident records. | Correct evidence links, reproducible handovers, bounded usage, permission and revision checks. |
| Limited officer pilot | Approved records and capture path, read-only assistance and reviewed drafts. | Measured correction rate, missed-important-fact rate, review time, latency and actual product usage. |
| Narrow action pilot | Specifically authorised clerical writes; computer use assessed separately if needed. | Exact diff review, idempotency, stale-version rejection, audit and recovery evidence. |
| Broader operation | Approved skills registry and role-scoped weekly reporting. | Access reviews, process-owner sign-off, monitored quality, support and validated economics. |

Compare equivalent tasks and quality criteria when evaluating savings. Include licence/credits, transcription, OCR, hosting, implementation, review and support costs. Set benefit targets after establishing a baseline; this showcase supplies no measured productivity or cost-saving result and makes no procurement or funding eligibility claim.

## 6. Official technical references

Sources checked 8 October 2026. Reconfirm against the selected tenant and current agency guidance at implementation time.

1. Microsoft — [Copilot Studio billing rates and management](https://learn.microsoft.com/en-us/microsoft-copilot-studio/requirements-messages-management).
2. Microsoft — [Choose a model and reasoning effort for Copilot Cowork](https://learn.microsoft.com/en-us/microsoft-365/copilot/cowork/cowork-models).
3. Microsoft — [Salesforce CRM search connector overview](https://learn.microsoft.com/en-us/microsoft-365/copilot/connectors/salesforce-crm-overview).
4. Microsoft — [Salesforce connector actions and prerequisites](https://learn.microsoft.com/en-us/connectors/salesforce/).
5. Microsoft — [Real-time speech diarization](https://learn.microsoft.com/en-us/azure/ai-services/speech-service/get-started-stt-diarization).
6. Victorian Government — [Guidance for safe and responsible use of GenAI in the Victorian Public Sector](https://www.vic.gov.au/guidance-safe-responsible-use-gen-ai-vps).
7. OVIC — [The limitations of de-identification](https://ovic.vic.gov.au/privacy/resources-for-organisations/the-limitations-of-de-identification-protecting-unit-record-level-personal-information/).
8. Microsoft — [Computer use in Copilot Studio](https://learn.microsoft.com/en-us/microsoft-copilot-studio/computer-use).
9. React — [React 19.3 release](https://react.dev/blog/2026/09/09/react-19-3).
10. xyflow — [Official React Flow releases](https://github.com/xyflow/xyflow/releases).
11. Motion — [Official changelog](https://motion.dev/changelog).
12. Motion — [Animation entry points and bundle choices](https://motion.dev/docs/react-reduce-bundle-size).
13. React — [Add React to an existing project](https://react.dev/learn/add-react-to-an-existing-project).
14. React — [`useSyncExternalStore` and cached snapshots](https://react.dev/reference/react/useSyncExternalStore).
15. React Flow — [Keyboard support and accessibility](https://reactflow.dev/learn/advanced-use/accessibility).
16. React Flow — [Panning and zooming](https://reactflow.dev/learn/concepts/the-viewport).
17. Anthropic — [Claude Haiku 5.5 announcement](https://www.anthropic.com/claude-haiku-5-5).
18. Anthropic — [Claude Haiku 5.5 model overview](https://platform.claude.com/docs/en/models/haiku-5-5/overview).
19. OpenAI — [GPT-6 Luna API model card](https://developers.openai.com/api/docs/models/gpt-6-luna).
20. OpenAI — [GPT-6 Astra announcement, dated Sol/Luna expansion update](https://openai.com/index/gpt-6-astra/).
21. Anthropic — [Claude Sonnet 5.5 model overview](https://platform.claude.com/docs/en/models/sonnet-5-5/overview).
22. Anthropic — [Structured-output compatibility and constraints](https://platform.claude.com/docs/en/build-with-claude/structured-outputs).
23. Anthropic — [Effort levels and model-specific guidance](https://platform.claude.com/docs/en/build-with-claude/effort).
24. Anthropic — [API pricing and context tiers](https://platform.claude.com/docs/en/about-claude/pricing).
25. OpenAI — [API pricing](https://developers.openai.com/api/docs/pricing).


## v1.6 presentation-layer addendum (8 October 2026)

The public-service journey now has seven explained steps, alongside six business and six token-efficiency steps. This is a local presentation upgrade, not evidence of a connected government deployment.

Guided and investor views consume the original controller snapshot. Stage navigation does not approve work, spend new model allowances or grant access. The expanded studio retains the twelve-node graph and optional routing explanation. Required transcript facts and a handover reserve continue to precede optional checks and skill drafts. Documents outside the officer fixture scope never enter the permitted body, highlights or exported summaries.

Prepared call -> facts -> unresolved questions -> permitted documents -> source-bound handover -> officer review -> permission plus exact field acknowledgement -> local sample update -> separately reviewed skill draft -> deterministic weekly workload.

A display of a model selection remains a proposal. There is no model call, actual speech recognition, computer use, Copilot-quota increase, tenant permission or production CRM write in this showcase. See the v1.6 source README for test scope and the separate deployment status.