A building block

A little help. A clear record.

dyna.ai - Passer user guide

Build a bot. Agree its boundaries. Follow the evidence.

Your organisation. Your operating rules. Build lending and servicing workflows with reviewed policies, controlled access and a record of the decisions behind the work.

Passer user guide

Try a voice colleague

Open the voice experience. The page reads current service availability. Each requested call follows its permission, eligibility, policy and budget checks.

Colleague Direction Start with Decisions that require care
Milo Outgoing Borrower name, example balance, days past due and consumer state Identity, third-party disclosure, contact limits, disputes, representation and distress
Fern Incoming Incident type, location, safety needs and reported policy details Emergency escalation, protected claim information, coverage and settlement decisions
Clover Incoming Service type, request, product and desired resolution Account authority, complaints, protected knowledge and requested human help
Casey Outgoing Vehicle, garaging state, insurance needs and enquiry permission Contact permission, licensed advice, quotations and binding decisions
  1. Select a colleague. Enter your name, your own permitted US number and the actual state relevant to the experience. An area code does not establish your present location.
  2. Review business details. Choose a configured voice and language. Advanced time, contact-history and identity settings describe an example scenario. They do not override actual call admission or verify a customer identity.
  3. Read and accept the request to use the supplied number for this experience. A separate verification call, text message or code is not required. The service checks that public numbers are eligible US voice numbers.
  4. Review the separate AI-call permission. Choose audio recording separately when supported. The initial contact request does not authorise audio recording.
  5. For Milo or Casey, select Call me. For Fern or Clover, select Prepare incoming experience, then call the displayed number from the number you supplied. Enter the private session code using your telephone keypad when prompted. The code expires with the session.
  6. Follow the transcript and Actual call decisions. Example policy scenarios use the retained launch configuration and never authorise the real call. Read their assumptions beside the results.
  7. Select End this experience to withdraw permission and request termination. Wait for the service's confirmation. A pending termination request is not proof that the telephone call ended.
  8. Review the summary and its evidence findings. Generated text or an audio-send event does not prove what you heard. Incomplete and unevaluated findings need review. The optional sales enquiry is a separate contact choice.

Set Scenario local time to explore calling-hour policy behaviour. It defaults to noon and controls calling-hour evaluation for this requested fictional demo. Real permission expiry, contact limits and budgets still apply. Organisation campaigns use the actual clock. A calling-hours refusal shows the evaluated demo time and window.

If the service cannot confirm eligibility or dispatch, retain the current experience and check its status. Do not repeatedly submit new requests or relaunch a call with an uncertain result. Your request records permission to contact the supplied number. It does not verify possession or customer identity.

Review an earlier phone call

In the logged-in workspace, open Results & audit → Call recordings, choose a call and use the player beside its transcript. Playback includes play, pause, seek, speed, elapsed time and duration. Select a timestamped turn to seek. Follow playback keeps the current turn visible and can be turned off while reading elsewhere.

A reviewer or operator can prepare approximate transcript timing for a supported retained recording. Auditors can read prepared timing. The original transcript remains unchanged. Missing audio and missing recording-relative timing are shown explicitly. See the full call-review guide for preparation, failures and access requirements.

Start with a bot

  1. Open Bots. Choose Create a new bot and Conversation workflow.
  2. Give the bot a title and purpose. Configure its start, agent, tool and end nodes. Set global instructions, declared transitions and typed variables. Classify each variable as public or protected.
  3. Select an active conversation action policy in the workflow editor and a separate active call admission policy. Select published knowledge versions and approved tools when needed. Choose a configured voice and language.
  4. Validate the graph and save the exact draft. Use Test Chat for prompt iteration or Test Audio for browser voice testing. Permit microphone access for audio. Unsaved changes require another save before testing. A draft test cannot place a telephone call or execute a production tool.
  5. Select Test configuration. A publisher uses Publish tested version when the saved checks pass. Keep chat/audio evidence with the version review. A configuration test alone does not establish call acceptance.
  6. Open Missions. Select the Published bot, enter the Mission title and Goal, and select Authorised owned destinations. Select Create mission.
  7. Inspect the saved mission before selecting start. Use Open operator console to follow calls and retained conversation evidence. Each mission keeps its bot and policy versions so another bot's settings do not silently change the work.

Existing mission and IVR bots retain Existing mission / IVR configuration. Their setup follows Purpose, Knowledge, Voice & tools, Boundaries and Review. Choose that mode deliberately when the workflow needs the existing IVR runtime.

For a batch, open Campaigns instead. Choose the published bot, enter the conversation goal and add owned destinations. You can paste one number per line or import a CSV with a destination column. The current limit is 100 unique targets per campaign.

From a regulation to a campaign

  1. Open Regulations & policies, then Regulatory sources. Add the official source and inspect its retained text and proposed interpretation.
  2. Use Enterprise Cedar policy editor to keep the exact Cedar source, schema, enterprise interpretation and test cases together. Set effective dates and reviewed history requirements. Validate source and schema and Evaluate with Cedar check the draft. A simulation does not authorise a call.
  3. Select Save policy draft, record the reason and use submit, approve and publish under the appropriate roles. Review is independent of authorship. Publication requires passing allow and deny tests.
  4. For an active policy, select Prepare a campaign under this policy. The form lists compatible published bots. If none exists, use Build a bot with this policy and complete its publication first.
  5. Enter the campaign name, goal, schedule and owned destinations. Select Save campaign draft, then Run preflight. Review each target's eligibility and explanation.
  6. A different authorised operator selects Release campaign. Each due call receives fresh admission checks against its pinned versions, current restrictions and available budget. Pause future calls and Cancel future calls control further dispatch. They do not establish the outcome of a call already in progress.

Policy comparisons use saved versions. Create restoration draft from this version retains the source version and starts a new review. Check its inherited effective dates before submission. Restoring a draft does not replace an active policy.

Work that lasts beyond one call

Open Missions → Durable workflows.

Prepare and review workflow templates supports two owned-test journeys:

  • T04 / Insurance enquiry callback waits for authenticated callback acceptance and an authorised disposition.
  • T05 / Collections source update waits for authenticated source-outcome confirmation and an authorised disposition.

An administrator must configure an authenticated owned-test source connector. An author selects that connector, permitted dispositions, maximum attempts, spend and duration. Use Save template draft, then the independent Submit template, Approve template and Publish template steps.

Under Start an approved workflow, select the approved template, permitted mission and assigned owner. Enter the objective and source subject reference, then select Start workflow. The reference must match the configured source's scope.

The detail shows owner, current step, wait reason, next action, deadline, attempts, spend and evidence. Unknown usage is labelled Unknown. Available actions depend on current server permissions and workflow state.

Use a recorded reason to pause, reassign or select an approved branch. Resume workflow requires an approved branch. The assigned owner records a disposition. Verify evidence and close succeeds only when the server finds the required authenticated source receipt and authorised disposition. A transcript or completed carrier call alone is insufficient.

Pausing or reassigning work fences an already scheduled callback. Reconcile that callback before preparing a new reviewed workflow. Late source updates remain evidence and do not reopen completed work. Use Close unresolved when the evidence cannot establish the objective.

Follow calls, results and evidence

  • In Campaigns, use Refresh campaign results and inspect each target's state and call link. Open the operator console for Passer conversation evidence. Results & audit → Call outcomes also retains the earlier Voice Call workflow, so use the linked mission when reviewing a Passer call.
  • In a mission, expand Inspect carrier state, select the existing incoming or outgoing call and enter a reason. Inspect existing carrier operation asks about that operation without placing another call. Terminal carrier evidence queued means persistence may still be pending. Refresh call records checks the saved state. An unresolved result does not authorise a repeated call.
  • An Auditor uses Download mission evidence or Download workflow evidence. Keep the full exported envelope. Its digest covers the exact UTF-8 canonical_payload string. The workflow package contains a separately verifiable mission package. Read all omission and scope markers before drawing a conclusion.
  • Results & audit → Audit evidence offers Verify and download audit. The retained chain supports internal verification. Independent external immutable anchoring is not configured.
  • Insights groups persisted records and links to the underlying rows. Counts and transport states do not prove payment, an accepted claim or another business outcome.

People, bots and organisations

Use named accounts. Voice Author prepares bots, policies and campaigns. Voice Reviewer reviews policies. Voice Publisher publishes approved versions. Voice Operator releases campaigns and supervises missions and workflows. Voice Auditor verifies and exports evidence. Administrators configure access and services. Business approval still uses the required named role.

Create separate bot versions for different purposes. Each mission pins its published bot and policy. Select the correct mission before taking action. Users in one organisation see only records their roles permit.

Each tenant uses a separate Frappe site and database, credentials and private runtime storage. A tenant is not a label entered in a campaign. Tenant provisioning and identity integration require administrator setup. Sign in to the intended organisation before accessing its workspace. This release does not provide a self-service tenant switcher or claim enterprise identity-provider integration is complete.

Current operating scope

Customer calling is enabled per organisation by its operator. Missions and campaigns require the current reviewed admission policy, authorised contact records and the organisation's configured operating limits. The separate public voice experience admits eligible US numbers under its own permission, policy and budget controls. Use fictional information in demonstrations; connect customer data only within your organisation's authorised workflow.

Source-confirmed T04 and T05 acceptance uses authenticated test connectors. Live insurer, lender, payment and consent integrations require implementation and acceptance before customer outcomes can be claimed. Current operational restrictions still apply to owned tests.

Browser operator assistance and hand-back are available through the operator console. A handoff record is a request for human help. It does not establish that an external telephone transfer occurred. Do not assume call recording or an external transfer is enabled. Recording permission and consent must be explicit, and the integration must be configured and accepted.

Use this guide for the current Passer workspace. Earlier operating instructions have been retired.

Share a completed demonstration

After a call ends, preview and save a read-only experience for colleagues. Choose whether to include the transcript and recording. Anyone with the link can view the selected content without signing in. Links expire within 30 days and can be revoked from the original experience.

See sharing permissions, playback and API details.


Review a recorded call

Sign in to Passer. Open Call recordings in the voice workspace, then select a call. Your assigned role and access to the parent call or mission determine which records you can review.

Listen and follow

Use the audio controls to play, pause, seek or change playback speed. Elapsed time and duration refer to the recording. Changing the selected call resets the player and transcript-follow state. The transcript appears beside the recording. When timestamped turns are available, select a turn to seek to that point. Follow playback keeps the current turn visible. Switch it off to read another part of the transcript while listening.

A transcript without recording-relative timestamps remains readable. Its wall-clock timestamps are not seek positions. A reviewer or operator can request Align transcript to recording for a supported retained recording. Preparation runs in the background. The review shows progress and offers Retry transcript timing if preparation fails. Resolve the reported failure before requesting a retry. An Auditor can read prepared timing but cannot request preparation.

Generated alignment is approximate. It maps the saved transcript to the recording and preserves the saved words and speaker labels. Listen to the audio when timing or wording matters. The alignment does not certify that the transcript is complete or accurate.

Missing recordings

A call can have a transcript without retained audio. The review shows when no recording is available. It does not create a recording for a past call or substitute browser speech for the conversation.

If your access changes, audio playback and transcript access may stop. Ask your administrator to check your role and the record's access restrictions.

Administrator notes

Recordings remain private. Each audio request checks the caller's permissions. The server retrieves audio from a configured provider or a private call attachment. It does not expose provider credentials or accept arbitrary recording URLs.

Alignment needs its enabled site setting, configured provider credential and a worker with access to the recording source. Historical Dograh recordings require the worker's Dograh connection settings as well as the web backend's settings. A worker failure before provider access does not establish a provider outage.

Prepared alignment and the matching audio use a private cache with a seven-day expiry and hourly cleanup. The original call record and recording follow their own retention settings. Disable new alignment requests with the site setting when the processor has not been approved for that organisation.

API

Authenticate each request with a Frappe session or Authorization: token API_KEY:API_SECRET. Session mutations also require X-Frappe-CSRF-Token. Never embed a service key in a public web page.

Method Endpoint Purpose
GET /api/method/dyna_control.call_review.calls List visible calls. Use limit and offset.
GET /api/method/dyna_control.call_review.detail Read one call's review data. Supply doctype and name.
GET or HEAD /api/method/dyna_control.call_review.audio Retrieve authorised audio. Supply doctype and name. Supports one HTTP byte range.
POST /api/method/dyna_control.call_review_alignment.prepare Request preparation for a call. Supply doctype and name.
GET /api/method/dyna_control.call_review_alignment.status Read preparation status. Supply doctype and name.

Supported record types are Passer Call and Voice Test Call. JSON methods return business data under message. The audio endpoint returns binary audio. HTTP 206 indicates a byte range and 416 indicates an invalid range. Treat HTTP 403 as an access denial. Do not repeatedly retry it.

Example using an environment variable populated by your secret manager:

bash curl --get 'https://passer.dynaai.us/api/method/dyna_control.call_review.detail' \ -H "Authorization: token $PASSER_API_KEY:$PASSER_API_SECRET" \ --data-urlencode 'doctype=Passer Call' \ --data-urlencode "name=$PASSER_CALL_ID"

Use the authenticated OpenAPI endpoint for the deployed method list. Call-review access does not grant permission to publish policies or launch calls.