Source systems
Email, chat, docs, CRM
Work originates in systems the company already uses.
Connector scope and source coverage
For investors, CDAIOs, and technical reviewers
Why reconstruction beats retrieval — by design.
RAG optimizes relevance. Neither optimizes reconstruction. Chief of Staff and Context API share one maintained graph — event ledger, time-scoped identity, provenanced causality, and negative-space checks. Neither is building toward detective-grade company context — measuring whether the system can reconstruct what happened, not just retrieve related documents.
System diagram
Architecture diagram
The full source-to-output path in one reviewable flow.
Each stage changes what the system may know, return, or expose.
StageWhat entersWhat changesWhat reviewers inspect
Ingestion
Connected records
Adds timestamp, owner, and workspace scope.
Data boundaries and ownership fields
Context graph
Structured objects
Links people, companies, projects, decisions, dependencies, and evidence.
Provenance and relationship quality
Governance
Graph query
Checks permissions, freshness, citations, and fail-closed behavior.
Deny states and fallback behavior
Surfaces
Approved context
Renders Chief of Staff or returns Context API output.
Audit trail and output shape
Data model, provenance, boundaries, and product surfaces are checkpoints on the same source-to-output path.
Control model
Controls sit between the graph and every output.
What keeps returned context scoped, reviewable, and safe to act on.
ControlWhat it doesWhat reviewer checks
Permission boundaries
Queries are limited by workspace keys and capability scopes.
Review scope rules and key rotation.
Freshness gates
Stale context is visible before a team acts on it.
Review timestamps and stale-data behavior.
Source visibility
Every returned object can point back to evidence.
Review citation and provenance fields.
Fail-closed behavior
Ambiguous or out-of-scope requests are withheld or denied.
Review deny states and fallback behavior.
Audit trails
Requests, sources, outputs, and handoffs remain reviewable.
Review logs and export path.
Deployment model
A staged path from SaaS to stricter isolation.
How stricter controls are introduced over time.
Stage 1
Hosted Neither SaaS
Use for: First review and hosted rollout
Adds: Hosted ingestion, graph services, Chief of Staff, and Context API
Stage 2
Workspace-specific controls
Use for: Scoped team rollout
Adds: Scoped keys, review artifacts, and rollout checks
Stage 3
Customer-managed isolation
Use for: Stricter procurement or regulated environments
Adds: Customer-managed or VPC-style isolation where required
Stage 4
Expanded audit exports
Use for: Regulated-team controls
Adds: Review exports and procurement-specific controls
Model and framework neutral
The same governed graph supports OpenAI, Claude, internal agents, and custom tools through the API.
Review artifacts
Artifacts for security, API, data, and rollout review.
The materials a reviewer uses to validate the system.
ArtifactReviewer questionWhere it sends them
Security overview
How are controls, boundaries, and posture reviewed?
Security
API reference
What will the API return?
API docs
Deployment posture
How does isolation change over time?
Deployment model
Data handling
How are freshness, citations, and evidence access handled?
Security controls
Rollout review
How do controls, integration path, and procurement fit together?
Get early access
Use these artifacts to review controls, integration shape, deployment posture, and rollout path.