Documentation
Canopus is the platform. It runs on the Vela substrate: finding bundles (vf_*), frontiers (vfr_*), bridges (vbr_*), events, signatures, and proof. Start with the product paths, then read the source documents that define the protocol and release contracts.
Canopus keeps each object in one authority lane. Engine work can guide attention, but accepted review events write the frontier record. Body maps stay derived.
| primitive | lane | home | authority boundary |
|---|---|---|---|
| source material | engine | Workbench | Input material. It can support a finding only after extraction, checks, and review. |
| finding bundle | record | Records | Canonical object after acceptance: assertion, evidence, conditions, provenance, confidence, and links. |
| frontier | record | Frontiers | Durable home for accepted state, correction history, proof, sources, and review events. |
| reviewable change | engine | Workbench or review | Proposal packet. It can guide work, but it does not mutate the record until accepted. |
| accepted review event | record | Records or trails | Mutation boundary. This is where accepted work becomes frontier state. |
| capability record | engine | Capabilities | Declared engine support: reads, output lanes, limits, checks, and agent usage. |
| campaign item | engine | Campaigns | Coordination material: targets, attempts, gates, validation, and packets before review. |
| proof packet | release | Trust | Release boundary. It freezes and exports accepted state; it does not add new findings. |
| atlas | body | Atlases | Derived map over accepted frontier state, bridges, gaps, and proof freshness. |
| constellation | body | Constellations | Field-scale body composed from atlases and frontiers. It guides navigation, not authority. |
The main surfaces follow the record, engine, and body model. Agents, capabilities, activity, trust, and docs support those layers; they are not separate product layers.
record
recordCanopus overview: active frontiers, campaigns, and recent state changes
open surface →
record
canonicalStart here to inspect the durable record: finding bundles, sources, links, review events, proof state, and correction history.
open surface →
record
object indexInspect substrate object counts across finding bundles, source records, evidence atoms, review events, proof packets, evaluations, and attestations.
open surface →
engine
write pathUse the local write path to add sources, inspect attempt packets and reviewable changes, and accept or reject changes against a frontier.
open surface →
engine
coordinationCoordinate frontier work through targets, attempts, failures, checked changes, evaluations, and external validation records.
open surface →
engine
full-stateSearch across frontiers, findings, signals, atlases, constellations, agents, capability records, and derived index surfaces.
open surface →
body
derived mapInspect domain-scale maps composed from accepted frontier state, bridge status, gaps, and stale proof cells.
open surface →
body
derived mapInspect field-scale maps composed from atlases, cross-domain bridges, and derived body-level state.
open surface →
body
derived mapWalk the cross-frontier graph: conjectured connections between frontiers awaiting a reviewer-gated transfer.
open surface →
body
derived mapInspect the findings in tension across the record: paired claims a reviewer must adjudicate, never auto-resolved.
open surface →
engine
engine agentsInspect engine agents, acceptance gates, composition, run contracts, and provenance-derived track records.
open surface →
engine
engine recordsBrowse declared engine capabilities for procedures, source connectors, checks, harnesses, compute systems, subject systems, and the boundaries they declare.
open surface →
engine
provenanceInspect the provenance ledger that credits agents, capability records, and systems for work left on frontier records.
open surface →
record support
proofReview traces, verifier keys, formal anchors, proof checks, and threat-model records that explain why state is trusted.
open surface →
record support
docsRead the platform, protocol, release, and conformance documents that define how Canopus runs on Vela state.
open surface →
engine support
resolverInspect the support resolver that maps Canopus slugs to content-addressed vfr ids across local and hub mode.
open surface →
These are the common work paths Canopus exposes across Home, Workbench, Search, and the command palette. Each path names the entry material, packet, gate, and accepted record effect.
source
Add source materialpacket
source record with provenance, locator, extraction method, and caveats
inspect source connectors →surface
open workbench →reproduce
Run a reproduction or benchmarkentry
task, benchmark target, code artifact, environment, and expected assertion
choose a campaign target →packet
attempt packet with logs, runner, input material, declared output material, and failure state
inspect harnesses →surface
open campaigns →surface
review queue →entry
declared input material, output lanes, auth boundary, version, and limits
browse capability records →accepted effect
engine capability linked to agents, runs, and affected frontiers
inspect agent usage →surface
inspect capabilities →surface
open atlases →These files define the platform model, substrate contracts, agent paths, and release obligations behind the product surfaces above.
CANOPUS_PLATFORM_CURRENT_STATE.mdThe active product model, canonical route families, capability namespace, retired route surface, and remaining consolidation rules.
CANOPUS_PLATFORM_SIMPLIFICATION_MEMO.mdThe phase log for route, navigation, capability, and contribution-workflow consolidation decisions.
CANOPUS_PLATFORM_REFERENCE_RESEARCH.mdLessons from science-adjacent, code, and knowledge platforms: durable typed objects plus reviewable state transitions.
platform/README.mdThe support-file map for engine record registries, Workbench context, executor specs, and archived platform plans.
PROTOCOL.mdThe shipped Vela language kernel for portable, correctable frontier state, finding bundles, events, proof packets, and content addressing.
AGENT_SDK.mdThe Python SDK shape for agents that produce signed Vela substrate artifacts and coherent frontier change sets.
AGENT_QUICKSTART.mdThe on-ramp for agents that read frontier state and draft reviewable changes under the same reviewer-gated path as humans.
PUBLISH_CEREMONY.mdThe deliberate local-to-hub checklist for publishing frontiers as public signed registry entries.
CONFORMANCE.mdThe public replay contract and fixtures an independent implementation can use to prove it agrees with Vela.