Private previewRelease candidate

Quaspar developer resources

Understand how Studio and Workspace support the full path from an engineering project to governed operation across healthcare and life sciences.

Studio

Build, connect, test, validate, and ship.

Workspace

Run, approve, inspect, and operate.

Lifecycle

Build → Test → Prove → Ship → Operate.

Browse documentation

Start here

The Quaspar lifecycle

The normal lifecycle is:

Build → Test → Prove → Ship → Operate → Inspect → Improve

A project begins in Studio, becomes an immutable version, passes the organization’s release gates, and is then shipped into Workspace for live operation.

Quaspar does not create a separate runtime for testing. Studio TEST and Workspace LIVE use the same governed runtime semantics, with different environment, identity, credential, policy, and write boundaries.

Core concepts

Organization
The tenant boundary for members, projects, knowledge, connectors, deployments, executions, approvals, and audit history.

Project
The engineering boundary inside Studio. A project can include source, an agent or workflow specification, tests, environment configuration, connector requirements, knowledge requirements, policies, and release evidence.

Agent
The logical system being built and operated.

AgentVersion
An immutable candidate or shipped version of an Agent. Releases should refer to the exact AgentVersion and artifact that was validated.

Environment
A development, test, staging, or production context. Quaspar also provides isolated synthetic TEST environments for healthcare and life-sciences engineering.

Deployment
A shipped AgentVersion bound to an organization and environment.

Execution
A run of a deployed or test AgentVersion.

Approval
A human decision requested by policy or runtime state before a governed action may continue.

Evidence
Structured operational or validation records that explain what happened without exposing hidden model chain-of-thought.

Quaspar Studio

Studio is the engineering environment.

Use Studio to:

create or import projects;
work from a repository;
edit source and project files;
use the coding assistant;
configure models, tools, connectors, and knowledge;
work with healthcare and life-sciences data structures;
create synthetic TEST environments;
run tests and simulations;
debug failures;
compare candidate versions;
inspect architecture and dependency impact;
validate a release;
ship an immutable version.

Guided, Code, and Advanced

Studio exposes three views of the same project.

Guided focuses on the goal, connected systems, required information, test plan, simulation, and release path.

Code focuses on files, editor, search, Git, the coding assistant, tests, and development tools.

Advanced exposes runtime, model, connector, context, policy, permission, cost, evaluation, architecture, and release evidence detail.

Changing views does not create a separate project or agent.

Repositories and source

Quaspar supports repository-native development.

For GitHub-backed projects, Studio can use the configured GitHub App to support repository connection, source inspection, fetch/pull, branch creation, commit, push, pull request creation, and diff workflows where enabled.

GitHub source is not production runtime truth.

The release path is:

Repository source → Build → Immutable AgentVersion / artifact → Validation → Ship

Quaspar does not silently merge pull requests.

Secret scanning should run before commit, build, and ship.

Local developer workflow

The Quaspar CLI is designed to support a workflow like:

quaspar auth
quaspar pull --project <id>
edit in the developer’s preferred editor
quaspar validate
quaspar push
quaspar build
quaspar test
quaspar simulate
quaspar ship --confirm

Production customer workloads do not execute on the developer laptop.

AI coding assistant

The Studio assistant can work with the project context the user is authorized to access.

It can help with:

code explanation;
repository search;
draft edits;
tests;
schema work;
connector implementation;
debugging;
project and dependency questions.

The assistant does not independently gain production authority. It cannot grant permissions, approve itself, obtain unrelated organization data, or silently ship a release.

Where Organization Intelligence is available, the assistant can answer questions grounded in the organization’s known engineering graph and evidence.

Knowledge and context

Quaspar can use organization-scoped knowledge and context such as approved documentation, SOPs, policies, interface specifications, source documentation, data dictionaries, and supported files.

Retrieval remains permission-aware.

Indexed content does not become trusted policy. Documents, repositories, webpages, and connected content are treated as untrusted data and cannot grant permissions, change organizations, approve actions, or expose secrets.

Where relevant, Quaspar can retain provenance for retrieved context so engineers can inspect which approved source influenced an output.

Healthcare engineering

Quaspar includes engineering primitives for supported healthcare workflows.

FHIR

Where implemented, Studio can provide:

resource inspection;
Bundle inspection;
request/response work;
validation of the currently supported subset;
synthetic examples;
mapping and transformation support.

Quaspar does not claim universal FHIR profile conformance unless a profile and validator are explicitly supported.

HL7

HL7 tooling is available where the implemented parser/workbench supports the message type being used.

X12 and NCPDP

X12 and NCPDP are extension points unless explicitly implemented for the current release. Unsupported formats should be shown as unavailable or not tested rather than simulated as fully supported.

Browser-based healthcare workflows

When a direct integration is unavailable, Quaspar can use governed browser workflows through the BrowserTask protocol and Chrome extension.

Browser actions remain subject to organization policy, approvals, session ownership, and runtime verification.

Life-sciences and research engineering

Studio is also designed for computational and research workflows.

Supported project patterns can include:

structured scientific datasets;
scientific documentation and protocols;
research knowledge;
data validation;
transformation pipelines;
computational workflows;
research reproducibility evidence.

Future systems such as LIMS, ELN, clinical-trial platforms, and scientific repositories should only be represented as connected capabilities when an actual integration exists.

Quaspar Environments

Quaspar Environments are isolated synthetic TEST environments for healthcare and life-sciences engineering.

They are not replicas of real customer organizations and do not clone production PHI or production credentials.

Available template concepts include:

Synthetic Hospital
Synthetic Clinic
Synthetic Payer Workflow
Synthetic Pharmacy
Synthetic Research Organization
Synthetic Biotech Lab
Custom synthetic environment

An environment may include supported synthetic FHIR resources, test interfaces, connector fixtures, browser portal fixtures, knowledge fixtures, event fixtures, and scientific datasets.

Reproducibility

Environment state can record version and seed information such as:

environment version;
dataset version;
schema version;
fixture version;
connector fixture version;
portal fixture version.

This makes test failures reproducible.

Fault injection

TEST environments can simulate supported failure modes such as:

connected-system timeout;
rate limiting;
schema change;
missing field;
authentication expiration;
portal change;
connector outage;
invalid response;
approval rejection.

Fault injection never modifies production systems.

Agent Twin

Agent Twin is Studio’s simulation experience.

It visualizes a TEST execution produced by the governed runtime.

A simulation can show the worker moving through stages such as:

Context → Model → Tool / Connector → Browser → Human Approval → Verification

Agent Twin supports timeline playback, stepping, inspection, and controlled test scenarios where enabled.

Simulation is visibly labeled SIMULATION or TEST RUN.

Simulation does not provide production write authority.

Scenario testing

Supported TEST scenarios can include:

missing data;
connected system unavailable;
portal changed;
connector timeout;
authentication required;
approval denied;
unsafe request blocked.

Counterfactual testing

Studio can run controlled test variants such as a different model or an unavailable connector. Results should come from actual TEST execution rather than speculative scoring.

Testing, debugging, and Exception Lab

Tests

Projects can define happy-path, edge-case, connector, browser, approval, recovery, policy, and domain-specific tests.

Debugger

The Studio debugger operates on TEST runs.

It can support controlled breakpoints before supported nodes, tool calls, browser actions, or connector writes.

Stepping and resume do not bypass runtime policy.

Replay

Replay is for safe test/debug workflows. It does not provide a shortcut to production writes.

Flight Recorder

Execution evidence can record structured operational facts needed to understand what happened without exposing hidden chain-of-thought.

Exception Lab

Exception Lab groups failure categories such as:

authentication;
authorization;
connector timeout;
schema mismatch;
insufficient knowledge;
invalid model output;
browser target changed;
approval rejected;
policy denied;
verification failed.

An engineer can turn an eligible sanitized failure into a regression test.

Live PHI should not be copied into test fixtures.

QuasparBench

QuasparBench compares candidate versions against the same repeatable benchmark suite.

A benchmark can define:

synthetic environment;
test cases;
expected outcomes;
verification rules;
failure scenarios;
performance measurements.

QuasparBench can measure items such as:

verified completion;
failure categories;
incorrect actions;
latency;
estimated or measured cost;
tool calls;
browser steps;
connector failures;
human intervention;
schema validity.

QuasparBench does not reduce results to a vague universal AI quality score.

Candidate results can be classified as:

candidate improved;
candidate regressed;
mixed results;
review required.

Organization-specific benchmark suites remain scoped to the organization.

Engineering Graph and Organization Intelligence

The Engineering Graph is derived from actual project and platform configuration rather than becoming a second source of truth.

It can represent relationships among:

projects;
agents and versions;
models;
tools;
connectors;
connected interfaces;
knowledge sources;
browser domains;
schemas;
tests;
policies;
approvals;
deployments.

Impact analysis

Engineers can inspect known blast radius before changing a connector, schema, model, knowledge source, tool, or policy.

Organization Intelligence

Organization Intelligence uses the Engineering Graph and existing evidence to answer grounded questions such as:

What uses this FHIR connection?
Which agents depend on this connector?
Which workflows access this knowledge source?
What tests protect this deployment?
Which browser workflows are unstable?
What changed between a successful release and a later failure?

Unknown relationships should be omitted rather than guessed.

Drift Sentinel

Where supported, Quaspar can flag known changes in:

connector schemas;
FHIR schemas;
knowledge source versions;
browser fixtures/pages;
model configuration;
dependencies.

Drift can trigger impact analysis and suggested validation. It does not automatically modify production.

Research reproducibility

For computational and research TEST runs, Quaspar can record a reproducibility pack containing supported identifiers such as:

source commit;
input dataset identifier and version;
environment version;
dependencies;
model/provider configuration;
schemas;
tools;
parameters and seed;
artifact hash;
execution evidence;
output/result hashes where appropriate.

An authorized user can reproduce an eligible TEST/research run using pinned versions.

Quaspar refuses silent substitution of a newer dataset or model. Any supported substitution should be disclosed in the resulting evidence.

This is technical reproducibility evidence, not a GxP or 21 CFR Part 11 certification.

Validation and controlled release

Studio provides technical controls that can support an organization’s change-control process.

A release can include evidence for:

source provenance;
AgentVersion;
artifact integrity;
dependency metadata;
tests;
benchmark results;
simulation;
permission changes;
model configuration;
connector requirements;
knowledge requirements;
security checks;
reviews and approvals.

Organizations may configure required release review and benchmark gates.

These controls do not, by themselves, establish HIPAA, SOC 2, GxP, or 21 CFR Part 11 compliance.

Shadow and progressive authority

Quaspar separates testing from production authority.

Shadow

Shadow uses a non-consequential test path to compare candidate behavior without granting production write authority.

Controlled authority

Organizations control how much authority a deployed system receives.

Authority can conceptually progress through levels such as:

Observe
Suggest
Read
Low-risk execution
Approval-gated execution
Authorized production execution

The agent cannot increase its own authority.

Ship

SHIP is the controlled transition from Studio to Workspace.

A release should bind an immutable AgentVersion to the target organization and environment.

A preflight can evaluate:

version immutability;
artifact integrity;
required tests;
required benchmarks;
validation;
permissions;
models;
connectors;
knowledge requirements;
browser requirements;
approval policy;
target organization.

Production credentials are not embedded into the AgentVersion.

Rollback

Rollback points to an exact previous immutable AgentVersion. It does not rebuild an old release from current source.

Quaspar Workspace

Workspace is the production operations surface.

It is not a second Studio and not a second runtime.

Workspace can include:

deployed agents;
agent status;
runs;
live workflows;
activity;
approvals;
authentication requests;
human takeover;
results;
evidence;
connection status;
deployment information;
usage;
audit information.

Workspace should clearly label live execution as LIVE PRODUCTION EXECUTION.

Studio simulations should remain clearly labeled SIMULATION / TEST.

Live Workflow

Live Workflow is driven by real runtime events.

A user may see operational stages such as:

Starting → Retrieving Context → Calling Integration → Browser Action → Waiting for Approval → Verification → Complete

Quaspar does not expose hidden model chain-of-thought.

Open in Studio

When a live execution fails, an authorized engineer can follow the execution back into Studio and inspect the associated project, version, evidence, Flight Recorder, or Exception Lab.

Agent Apps

A shipped AgentVersion can expose a safe operational interface inside Workspace.

Agent Apps are compiled from approved schemas and component primitives. They do not generate arbitrary untrusted React or JavaScript.

An Agent App can provide:

Overview
Run
Current / Recent Work
Approvals
Results
Evidence

Input controls can be derived from typed schemas.

A schema-declared action does not grant permission. Backend authorization remains authoritative.

Web and desktop

Quaspar Web and Quaspar Desktop are clients of the same platform.

They share:

account and organization;
projects;
versions;
deployments;
executions;
approvals;
runtime events;
permissions.

Desktop can add native capabilities such as:

local repository access;
file and folder selection;
native notifications;
deep links;
secure OS credential storage;
local engineering workflows.

Desktop does not receive extra production authority merely because it runs locally.

Unsynchronized local changes should be shown explicitly and must never silently overwrite cloud or Git state.

Chrome extension and browser workflows

The Quaspar Chrome extension executes governed BrowserTasks for authorized browser workflows.

The browser flow conceptually follows:

Runtime → BrowserTask → Authorized extension session → Browser action → Report → Runtime resume → Verification

Browser tasks remain scoped to the authorized organization, execution, session, and policy.

Human takeover and authentication can be requested when needed.

Authentication and authorization

Quaspar uses organization membership and server-side permissions to determine access.

Frontend visibility is not an authorization boundary.

A user who cannot access a Studio project must also be denied when calling the backend directly.

Studio development permission does not automatically grant Workspace production authority.

Production execution resolves permissions, connectors, knowledge, browser session, and approvals in the target organization context.

Security principles

Quaspar is designed around several core security rules:

Tenant isolation
Organization resources must remain organization scoped.

Least privilege
Agents, users, connectors, browser sessions, and services should receive only the access they need.

Immutable releases
Shipped releases should remain tied to exact immutable artifacts and versions.

Human oversight
Policies and approvals control consequential operations where required.

Untrusted context
Documents, websites, model output, and browser content cannot grant authority.

Secret isolation
Credentials are not returned in normal list responses and are not embedded into release artifacts.

TEST / LIVE separation
Synthetic environments, simulation, replay, and shadow must not silently gain production-write capability.

No hidden chain-of-thought exposure
Quaspar exposes structured operational evidence, not private model reasoning.

Availability and honest limitations

Quaspar documentation should distinguish among:

Verified in production
Verified in controlled testing
Requires live vendor validation
Requires customer-environment validation
Not ready

A passing test suite does not automatically mean a feature is production-ready.

Examples of capabilities that may require external validation include vendor sign-in, GitHub App behavior, model-provider credentials, EHR/FHIR systems, email providers, browser portals, desktop signing/notarization, backup restore drills, and customer-specific connector behavior.

The public documentation should never imply certification that Quaspar has not actually achieved.

Recommended first project

A safe first Studio project should use synthetic data.

Create or join an organization.
Open Studio.
Create a project.
Choose Guided or Code view.
Create a synthetic healthcare or life-sciences environment.
Describe or implement the workflow.
Configure required models, knowledge, and connectors.
Run tests.
Open Agent Twin.
Exercise at least one failure scenario.
Review validation and permission changes.
Prepare a release.
Ship only when organization release gates pass.
Open Workspace.
Run or monitor the shipped Agent App.
Inspect approvals, results, and evidence.
If something fails, open the execution back in Studio and create a regression test.