Space Usage Guide
Status: Derived operating guide
Applies to: Perplexity Space — Synedrix OS
Date: May 2026
This document does not replace any canonical Synedrix OS artifact. It explains how to use the existing canonical documents in this Space as the high-level source of truth for architecture, governance, and validation.
1. Purpose
This Space is the authoritative working environment for:
- Synedrix OS positioning and architectural reasoning
- validation of new proposals against canonical OS rules
- separation of concerns between Synedrix OS, domain packs, and business instances
- review of whether a proposed artifact belongs in the OS layer or outside it
- validation of domain-pack designs before they are treated as stable
This Space is not the primary build environment for domain-specific implementation details such as Trading workflows, domain event catalogs, or domain heuristics.
2. Role of Perplexity in Synedrix
Perplexity should be used here as:
- the reviewer of OS-level consistency
- the validator of architecture decisions against the canonical documents
- the challenger of proposals that blur OS vs domain boundaries
- the synthesizer of cross-document implications
- the place where strategic and canonical language is normalized before downstream implementation
Perplexity should not be treated as the main authoring environment for domain-pack build artifacts unless the task is explicitly to validate them against OS canon.
3. Layer routing rule
Before answering any design or architecture question, first classify it into one of these layers:
A. Synedrix OS Platform
Use this layer when the request concerns reusable substrate capabilities such as:
- agent definition schema
- registry semantics
- workflow contract standards
- event envelope standards
- runtime policy standards
- evaluation standards
- shared database schema
- platform stack responsibilities
- interoperability patterns
- governance and principle-level decisions
B. Domain Pack
Use this layer when the request concerns domain-specific business logic such as:
- domain entities
- domain workflows
- domain-specific agents
- domain event catalogs
- domain tools and adapters
- domain prompts, evaluators, and KPI vocabularies
C. Business Instance
Use this layer when the request concerns instance-specific configuration such as:
- credentials and secrets
- enabled workflows
- thresholds
- approver mappings
- tenant overrides
- environment-level routing or policy values
4. Canonical routing map
Use the following documents as the primary references for each question type.
| Question type | Primary canonical document |
|---|---|
| What is Synedrix OS and what is its role? | Synedrix OS - Core Principles |
| What is the complete executive view of the canon? | Synedrix OS - Consolidated Canonical Reference |
| Does this belong to OS, a domain pack, or a business instance? | Synedrix OS - Responsibility Matrix |
| What is an agent in Synedrix OS? | Synedrix OS - Agent Spec |
| How are agents registered and governed? | Synedrix OS - Agent Registry Spec and Synedrix OS - Agent Registry |
| How are workflows specified? | Synedrix OS - Workflow Contract Spec |
| How are runtime policies defined? | Synedrix OS - Agent Runtime Policy Spec |
| How are agents evaluated and promoted? | Synedrix OS - Agent Evaluation Spec |
| What are the shared event rules? | Synedrix OS - Event Taxonomy Standard |
| What are the platform layers and their meanings? | Synedrix OS - Layer Taxonomy Table and Synedrix OS - Taxonomy & Platform Spec |
| What infrastructure does Synedrix OS own? | Synedrix OS - Platform Architecture & Tech Stack |
| What is the broader architecture thesis? | Synedrix OS - Technical Platform Thesis |
| How does interoperability work? | Synedrix OS - Interoperability & Protocol Strategy |
5. Operating rules for this Space
Rule 1 — Canonical documents win
When a suggestion conflicts with a canonical document in this Space, the canonical document takes priority.
Rule 2 — No duplicate canon unless necessary
Do not create a new canonical document if the concern is already covered by an existing canonical artifact. Prefer interpretation, cross-reference, or versioned amendment.
Rule 3 — Protect the OS/domain boundary
If a proposal introduces domain-specific entities, tools, workflows, or event semantics into Synedrix OS without proving cross-domain reuse, reject it or reclassify it to the domain-pack layer.
Rule 4 — Use the responsibility matrix as a gate
When ownership is unclear, classify the concern by the responsibility matrix before designing the artifact.
Rule 5 — Validate before extending
Before suggesting a new OS artifact, first check whether the current canonical set already covers the concern through:
- principles
- taxonomy
- responsibility split
- workflow or event standards
- registry or runtime policy standards
- stack ownership
6. Standard review questions
When reviewing a proposal in this Space, answer these questions first:
- Which layer does this belong to: OS, domain pack, or business instance?
- Which canonical document already governs this concern?
- Does the proposal violate bounded autonomy, governance-before-execution, or scoped access?
- Does it preserve orchestration as the center of gravity?
- Is the concern reusable across domains, or is it domain-specific?
- Is a new artifact truly required, or is this a versioned extension to an existing one?
7. Recommended use with Claude Projects
Use Claude Projects as the implementation workspace for domain packs.
Recommended split:
- Perplexity / Synedrix OS Space: principles, canon, architecture review, ownership validation, and cross-domain consistency
- Claude / Domain Project: domain charters, domain workflows, domain agents, domain events, and implementation-first design inside the OS constraints
In practice:
- bring OS-level questions here first
- bring domain-pack drafts here second for validation
- keep domain-pack build artifacts in Claude unless they become reusable OS patterns
8. Promotion rule
A domain-pack pattern should only be promoted into Synedrix OS if it demonstrates clear reuse across multiple domains and fits the OS responsibility boundary.
Until then:
- the OS owns the framework
- the domain pack owns the implementation
- the business instance owns the local configuration and accountability
9. Status note
This is a lightweight operating guide. It is intentionally short and should remain derivative of the canonical Synedrix OS documents already attached to this Space.
Related Documents
Primary canonical documents routed by §4 of this guide
- Synedrix OS - Consolidated Canonical Reference — Complete executive view of the canon; the recommended first read.
- Synedrix OS - Core Principles — 12 governing principles; what Synedrix OS is and its governing constraints.
- Synedrix OS - Responsibility Matrix — Capability-by-capability ownership split; use as the gate when ownership is unclear.
- Synedrix OS - Taxonomy & Platform Spec — Canonical taxonomy; what belongs to OS, domain pack, or business instance.
- Synedrix OS - Layer Taxonomy Table — 12-layer architecture definitions.
Agent and Workflow References
- Synedrix OS - Agent Spec — What an agent is in Synedrix OS.
- Synedrix OS - Agent Registry Spec — How agents are registered and governed.
- Synedrix OS - Workflow Contract Spec — How workflows are specified.
- Synedrix OS - Event Taxonomy Standard — Shared event rules.
Index
- DOCS.md — Index of all documents in this repository with one-line descriptions.
Synedrix OS · Derived Space Guide · May 2026