A prototype exploring orchestration frameworks: a governed agent that turns a regulated-enterprise conversation into a decision-ready brief, safe follow-up actions, and an auditable work product.
Most AI assistants stop at an answer. OrcaStraight is designed for the higher-stakes moment after the answer: when a team needs to decide, route approvals, make a change, and prove what happened. The prototype uses a credit-committee workflow to show how an agent can be useful without being the authority that decides whether a consequential action is allowed.
This short walkthrough shows the product arc in action: a blocked discount request becomes a decision-ready brief, routes the required approvals, revalidates as the workflow changes, and ends as a sealed governed record.
▶ Watch the embedded demo · Watch on YouTube
In regulated workflows, a conversation rarely contains everything required to act. A proposed discount might exceed delegated authority, an approval may be missing, a source can be restricted, or a previously reviewed fact can become stale. A plausible summary is not enough; teams need a clear record of the decision, the evidence, the policy constraints, and the next safe action.
OrcaStraight makes that state visible. It is intentionally opinionated about three product principles:
- Ground the agent in permitted evidence. Responses carry access-aware citations; locked material is not revealed or inferred.
- Keep consequential decisions deterministic. The model may help with language, but policy gates, approval readiness, citations, and execution eligibility remain typed system decisions.
- Treat work as a lifecycle, not a chat turn. Returned approvals and source changes trigger revalidation; completed work can be sealed into a durable governed record.
The primary end-to-end scenario starts with a 22% discount request for Acme Corp. The agent identifies the missing Credit Officer and Legal approvals, blocks the write, drafts a decision brief, routes only permitted follow-up actions, recomputes the brief as approvals arrive, and seals the approved result with its evidence and policy trace.
| Product surface | PM question it answers |
|---|---|
| Meeting rail and private agent responses | How should an agent help in a shared setting without expanding another participant's access? |
| Decision Brief | What must be true before a team can responsibly proceed? |
| Agent Actions | How do proposed writes stay reviewable, policy-checked, and explicitly approved? |
| Revalidation and governed records | How do we preserve trust when source data or approvals change after a decision? |
| Agent Ops / eval scorecard | How do we measure safety and quality across finance, legal, and health workflows? |
Prototype demos usually blur the line between what runs and what is staged. This map is the audit instead of the pitch: every capability across the eight surfaces, checked against the code. Green paths execute on the backend, amber is deliberate simulation, and red is built and tested but not wired to the primary UI journey.
The short version: the decision logic is real; the other people are simulated. Approval readiness, the 22%-vs-15% threshold, blocked execution, staleness, and record verification are all computed. What is faked is human latency — clicking "simulate Credit Officer response" stands in for someone who is not in the room, so the walkthrough runs alone without live email or a second operator.
The docs assistant at /docs/chat is the densest piece of engineering in the repo, so it gets its
own band on the map. Permissions are applied to the index, not to the answer: a locked document
contributes its title and an empty body, and a sealed document contributes only its cleared
derivative, so there is no path by which a model sees text it should not have. Ranking weights
curated title and section text above body matches and length-normalizes the body score, so a long,
broad document cannot outrank a short, precise one on token volume alone.
The two parts worth a PM's attention are the ones that decline to answer. Below a relevance threshold the retriever returns nothing and the response names the aspects of the question it could not cover, rather than assembling a confident-sounding paragraph from weak matches. And any LLM draft is advisory: a grounding guard re-checks it against the evidence actually returned and rejects it for unsupported numbers, unsupported identifiers, citations that were never retrieved, leaked locked or sealed markers, or any claim to have overridden access control. A rejected draft falls back to deterministic prose. That is 64 tests' worth of behavior, and it is why the model can be swapped or removed without changing what the system is allowed to say.
Nine endpoints are deliberately listed as unreachable. Keeping that count visible is the point:
scope was cut at the UI layer, not quietly deleted from the repo, and the tests still cover it.
The same map ships inside the app at /developers/whats-live.
The system separates generative assistance from deterministic control points. Shared typed contracts define the pipeline, so each stage is independently testable and can be replaced without changing the product boundary.
intent → ContextAssembler → Verifier → BriefSynthesizer
→ ActionComposer → [human approval] → Executor
→ RevalidationEngine ⟲ | EvalRunner + TelemetryEvent
- Evidence and permissions: context assembly filters sources before synthesis; the API returns citations and honest missing-evidence states.
- Policy as product: independently testable rules evaluate approvals, thresholds, permissions, and freshness. A blocked action stays blocked even if a user or model asks to bypass it.
- Human-in-the-loop execution: the UI presents proposed diffs and routes; only approved, unblocked actions can execute.
- Privacy-aware evaluation: telemetry uses typed, redacted aggregates rather than raw prompts, responses, or document content. The same substrate is exercised by finance, legal, and health recipes.
The frontend provides four connected prototype surfaces: a meeting side panel, a decision-packet workspace, an action drawer, and an Agent Ops scorecard. It runs in deterministic mock mode by default, making the governed workflow reproducible without credentials.
# Terminal 1 — API
make install
make serve
# Terminal 2 — frontend
cd frontend
bun install
bun run devOpen http://localhost:5173/ to follow the Acme scenario. For the scripted path and expected
states, see DEMO_RUNBOOK.md. To connect the UI to the API instead of bundled
mocks, set VITE_USE_MOCKS=false and VITE_API_URL=http://localhost:8000 in frontend/.env.local.
The repository is designed to make product behavior inspectable, not merely demoable.
make test # Python unit and integration tests
make lint # Ruff checks
make eval # Finance, legal, and health evaluation scorecard
cd frontend
bun test # UI and docs-extraction tests
bun run build # Production buildcore/— shared contracts and pipeline protocols.verification/— deterministic policy checks.actions/andlifecycle/— governed execution and revalidation.api/— FastAPI gateway, governed chat, records, and observability endpoints.frontend/— React prototype surfaces.recipes/,evals/, andtelemetry/— cross-vertical rules, evaluation, and privacy-preserving measurement.
This is a portfolio prototype, not a production deployment. The governed-record store and lifecycle event state are in-memory; external integrations are simulated; and the deterministic path is the source of truth for tests and demos. Those boundaries are deliberate: the project focuses on product architecture, safety decisions, and an explainable end-to-end experience.