Intent
Task and expected outcome
Conceptual architecture
A control plane for trusted intelligence.
PULSAR separates the durable control plane from replaceable models, tools and knowledge systems—creating one governed path from intent to outcome.
Conceptual request map
One request. A governed path.IntentPerson, application or bounded agent
Trust gateIdentity · authority · purpose
Adaptive routeRisk · quality · latency
Permitted contextKnowledge · tools · provenance
Evidence gateGrounding · uncertainty · review
Accountable outcomeAnswer · action · audit trail
Sovereign boundaryAdaptive routingPermission-aware contextHuman authority
01 / Request lifecycle
From intent to accountable outcome
Eight observable stages make routing, authority and evidence explicit.
Identity
Who or what is asking
Policy
Purpose, scope and risk
Route
Capability path selection
Context
Permitted knowledge and tools
Runtime
Fast, deep or escalated execution
Verification
Evidence, uncertainty and review
Outcome
Response, action and trace
02 / Adaptive model paths
Use the smallest capable path first
The tiers describe operating intent—not fixed model sizes or permanent assignments.
FAST
Responsive default
Routine classification, retrieval, extraction and short-form assistance.
Low frictionMEDIUM
Deeper working path
Multi-step synthesis, richer context and domain-oriented reasoning.
Measured depthFRONTIER
Selective escalation
Novel or demanding work that earns additional depth and review.
Explicit gateRoutine
Escalate when evidence requires
Public vision graphics
Architecture, made visible
Open full size ↗The governed request path
Eight visual stages move from intent and identity through policy, routing, context and execution to verification and an accountable outcome.
Open full size ↗Adaptive capability paths
Fast, Medium and Frontier represent replaceable operating paths. Low confidence can trigger escalation; consequential outcomes retain human review.
Manifesto & rationale
The thinking behind the system
The stable layer around changing intelligence
The platform is designed as a set of open boundaries rather than one inseparable stack. Each layer has a specific responsibility and an observable contract with the next.
Access and policy
Requests begin with identity. The runtime evaluates who or what is asking, the purpose of the request, the permitted data boundary, the available tools and the risk class of the task.
Gateway and routing
A consistent application interface applies quotas, request validation and trace context. A router then chooses an appropriate capability path according to task type, quality, latency, cost and risk signals.
Context and tools
Retrieval introduces only information the requesting identity is allowed to use. Tool calls operate through explicit allowlists, bounded execution and approval points. Context carries source and permission metadata forward.
Model runtime
Fast, medium and frontier capability tiers provide different balances of responsiveness and depth. The tiers are planning concepts—not fixed parameter counts or permanent model assignments.
Verification and observability
Outputs can be checked for grounding, policy compliance and uncertainty. The runtime records enough context to explain which route was taken, what evidence was used and where human review remains required.
Replaceability is a feature
Models, retrieval engines, serving runtimes and storage technologies will continue to change. PULSAR treats that change as expected. Open interfaces, versioned contracts and evaluation gates allow components to evolve without dissolving the trust boundary around them.
Two planes, one responsibility
The control plane manages policy, identity, routing, model lifecycle, evaluation and service health. The data plane executes requests, retrieves permitted context, invokes approved tools and serves model output.
Separating these concerns makes ownership clearer and helps high-impact changes pass through explicit validation before they affect live workloads.