COLLECTIONRESEARCH SNAPSHOT · 6 NOVEMBER 2026

Resident assistant / Evaluation plan

O. concierge

Four views of the assistant, and the evidence needed before an internal pilot.

Development scope. No readiness verdict.

This public page summarises inspected source and proposed evaluations. No staging evaluation result is verified. It contains no resident records or operational credentials.

Verified in source Inspected implementationProposed Work to evaluateUnknown Evidence still needed

View 01 / Data flow

Authorise first. Project before the model.

Each tool runs with the resident’s permissions. The model receives selected fields; the device receives the result for its cards.

  1. Resident

    Verified in source

    A question about an authorised home or unit.

  2. API authorisation

    Verified in source

    Session, building scope and assistant permission are checked.

  3. Protected tools

    Verified in source

    Read routes run in process with the resident’s credentials.

  4. Model projection

    Verified in source

    Selected fields ground the answer. Payment amounts can reach the model as formatted text.

  5. Answer and cards

    Verified in source

    Streamed answer plus device cards. Contact details and links stay outside the model projection.

View 02 / Infrastructure

One API Worker, with a managed model path.

Source config enables AI in staging. This is a source snapshot, not a verified deployment diagram or a production readiness claim.

  1. Mobile app

    Verified in source

    Resident assistant on mobile.

  2. API Worker

    Verified in source

    The assistant runs inside the API Worker, with protected tools and conversation storage.

  3. Cloudflare AI Gateway

    Verified in source

    Custom provider route through the Vercel AI SDK (Software Development Kit).

  4. Microsoft Foundry

    Unknown

    Configured staging deployment: gpt-5.6-luna. Exact deployed model revision remains unverified.

View 03 / Connections

Streaming answers and confirmed actions take separate paths.

The stream may propose an action. A separate backend request confirms or declines it. The model cannot execute a write through the stream.

  1. Resident question

    Verified in source

    POST to the protected assistant stream endpoint.

  2. Server-sent events

    Verified in source

    Text, tool results, suggestions, questions and review frames return to the client.

  3. Review proposal

    Verified in source

    Backend owns the proposal, a snapshot and a 15-minute confirmation window.

  4. Explicit decision

    Verified in source

    Confirm rechecks ownership, expiry and snapshot. Decline withdraws the proposal without a write.

  5. Outcome

    Verified in source

    A claim and an idempotency key prevent duplicate execution. The backend returns the action outcome.

View 04 / Salesforce behaviour

Keep source boundaries visible from read to write.

Salesforce sandbox, platform records and fixtures have different roles. A missing record must not be presented as a failed source.

  1. Owner and unit scope

    Verified in source

    Resolve the resident’s authorised home before reading a record.

  2. Protected read

    Verified in source

    The API uses its connector binding to reach the connector service and Salesforce sandbox.

  3. Mixed sources

    Verified in source

    Payments and relationship manager use the connector; journey and visit records include platform mirrors. Construction content includes fixtures.

  4. Projected response

    Verified in source

    Selected fields inform the grounded answer. The device renders cards from the route result.

  5. Confirmed cancellation

    Verified in source

    The platform updates its own visit record, then mirrors the change asynchronously to Salesforce.

Current evaluation baseline

A suite exists. A result is still needed.

10Pre-Handover cases
3Default repeats
100%Default configured bar, not a score

The inspected suite uses fixed-rule checks. Four required cases must pass every run. No verified staging result is available here.

An unmerged proposal expands the suite to 58 cases and proposes a 90% bar. These are not the current baseline or approved acceptance criteria.

Proposed sequence

Earn the pilot with evidence.

  1. Agree acceptance criteria with Product and Legal, including critical authorisation and action failures.
  2. Extend coverage, label human examples and verify mobile confirmation.
  3. Run repeatable staging evaluations with privacy-reviewed telemetry and preserve the results.
  4. Review evidence for a limited internal pilot. Production needs a separate decision.
Sources, runtime limits and interpretation

Research date: 6 November 2026. This page uses the recorded source inspection from that date. Source verification does not prove deployed behaviour.

  • Collections source snapshot becc5fd: assistant/src, tool registry in apps/api/scripts/contracts/ai-tools.json, and evaluation suite in e2e/eval.
  • Mobile source snapshot 30b66fb: src/features/assistant. “O. concierge” is the name used for this evaluation request.
  • Source limits: 5 model steps, final step answer-only, 20 seconds per step, 45 seconds per turn, 4,096 output tokens and no model retries. Rate limits: 15 stream and 30 action requests per user per 60 seconds.
  • Registered tools: 11 reads and one cancellation action. Built-in clarification and answer completion are separate. No retrieval-augmented generation or vector store is evidenced.
  • Staging “live” Salesforce access means sandbox access. Development previews and construction fixtures do not prove live field mappings.
  • Evidence is still needed for provider processing region, exact deployed model revision, retention and erasure controls, production topology and approved pilot criteria.