Field evidence
Pulsar Field Notes
Evidence-bounded notes about specific Pulsar deployment patterns and controlled workflows.
Pulsar Field Notes document a specific implementation path with a narrower claim than a general guide. Each note identifies what was reviewed, the environment class used for the review, the outcome that evidence supports, and the limitations a reader must preserve when applying the pattern elsewhere.
How to read a field note
- Evidence status: whether the note is based on code inspection, configuration review, a bounded QA exercise, or a combination.
- Verification scope: the precise behavior reviewed, such as runtime placement or approval enforcement.
- Outcome: what the evidence supports without turning a local observation into a universal claim.
- Limitations: conditions not measured or guaranteed, including performance, high availability, and external infrastructure controls.
Current notes
Split Compute and GPU Runtimes explains how the Pulsar application and state services can remain on one deployment while primary inference or creative workloads run on approved GPU services elsewhere. It focuses on ownership, network paths, failure behavior, and verification rather than unsupported throughput claims.
Approval-Gated Pulsar Code Change follows a repository task from a pinned base revision through an isolated run, evidence review, a single-use branch-push approval, and a separately approved draft pull request. It does not imply merge authority or direct default-branch writes.
Evidence is not a guarantee
A field note is a reviewed technical record, not a customer endorsement, benchmark, compliance report, or promise that every environment will behave identically. Re-run the relevant checks against your own network, runtime, identity, and recovery controls before production use.
Apply notes responsibly
Preserve the stated boundary when adapting a note. If runtime placement, repository permissions, identity, storage, or network controls differ, record the difference and repeat the affected verification. A changed environment can support a different conclusion even when the visible workflow looks similar.
Continue with the durable product model
Use Pulsar Architecture for the complete component and trust-boundary model. Use Planning a Pulsar Deployment to translate a field-note pattern into a deployment decision. Use Operating a Private AI Workspace to turn the result into health, backup, recovery, and approval procedures.

Split Compute and GPU Runtimes
Keep the Pulsar application and state services together while placing approved inference or creative runtimes on separate GPU hosts.
Read more
Approval-Gated Pulsar Code Change
Follow a Pulsar Code task from a pinned repository state through isolated evidence, exact branch-push approval, and a separately approved draft pull request.
Read morePrivate deployment consultation
Review Pulsar against your environment.
Bring the infrastructure, security boundaries, model runners, and use cases. The Pulsar team will map the appropriate deployment path.