Skip to main content

Working with DASHA, CARA, and VERA

This guide covers the supported workflow in an already deployed CodeGraph instance. Obtain the server address, authentication method, and access rights.

User Guides

This guide covers the supported workflow in an already deployed CodeGraph instance. Obtain the server address, authentication method, and access rights from your environment administrator.

Run an analysis

  1. Open /dashboard/onboarding-research.
  2. Select the investment_construction_dynamic preset.
  3. Choose the starting role: DASHA, CARA, or VERA.
  4. Review the suggested question and edit it if necessary.
  5. Start the analysis and wait for the final response.

For this preset, the interface automatically attaches a bundled workbook with project and cost data and a schedule excerpt. Custom file upload is not supported on this page. The result therefore describes the demo data, not your project files.

Role responsibilities

  • DASHA — Data Acceptance, Screening & Harmonization Agent — assesses whether input data is suitable for analysis.
  • CARA — CAPEX At Risk Agent — identifies CAPEX-risk candidates and mapping problems.
  • VERA — Verified Execution Reporting Agent — checks whether available evidence supports claims of actual execution.

The results support professional review. The responsible specialist records professional judgment and budget, contract, payment, or acceptance decisions.

Continue a session

After the first response, use an action that is available for the current session:

  • confirm_mapping confirms a proposed data mapping;
  • continue advances the current analysis;
  • clarify requests clarification;
  • transfer passes typed evidence to the next role;
  • cancel stops the current workflow.

The available controls depend on session state. During a transfer, the next role receives a typed_evidence_package, which carries the structured evidence from the previous response.

Interpret the result

Start with the execution metadata:

  • completed means that the workflow completed its planned steps;
  • partial means that a limited result is available and must be read with its constraints;
  • blocked means the workflow could not continue safely, with a reason included in the result;
  • fallback means that a deterministic fallback path was used.

fallback is not necessarily an error, but the result must not be presented as a model-provider answer. Review its provenance, missing inputs, and evidence list. The progress tracker provides waiting feedback in the interface; the final status, provider metadata, and evidence package are the authoritative execution signals.

Then review the role-specific content:

  • for DASHA, check input quality, assessment scope, and data gaps;
  • for CARA, check the basis of each risk candidate, mapping conflicts, and assumptions;
  • for VERA, check evidence of actual execution and the missing-document list.

Recover from a blocked or partial result

  1. Read the blocked reason or partial limitations.
  2. Do not use one role’s output to strengthen another role’s unsupported conclusion.
  3. Use clarify when available, or confirm_mapping when the workflow requires a mapping decision.
  4. For an environment problem, give the administrator the session identifier, final status, and provenance metadata. Do not include secrets or restricted project documents.

Retry after correcting the input or environment. Repeating the same request does not supply missing evidence.

Verifiable contract sources

  • src/investment_construction_agents/pack.py — DASHA, CARA, and VERA;
  • src/investment_construction_agents/dynamic_workflow.py — actions, statuses, and typed_evidence_package;
  • src/api/services/core_services/chat_service.py — the investment_construction_dynamic preset, metadata, and fallback behavior;
  • frontend/src/pages/OnboardingResearchChat.tsx — route, controls, and bundled demo input.