-
Notifications
You must be signed in to change notification settings - Fork 0
Operational Model
Weave Skills operates as a filesystem-native operational system for long-running engineering workflows.
The system is designed around:
- contextual continuity
- implementation grounding
- bounded operational behavior
- deterministic-safe behavior
- and lightweight contextual overlays
inside real engineering repositories.
The operational model is built around a simple separation:
The runtime preserves invariants.
The agent performs inference.
This became one of the strongest stabilizers in the architecture.
The separation intentionally prevents:
- ontology escalation
- runtime inflation
- repository semanticization
- graph authority drift
- and operational fragmentation
The architecture separates operational responsibilities across layers.
| Layer | Responsibility |
|---|---|
| Filesystem | Authoritative structure |
| Runtime | Invariants |
| Serializer | Canonical structure |
| Skills | Operational capabilities |
| Agents | Inference |
Each layer intentionally remains bounded.
The filesystem remains authoritative.
Repository structure preserves:
- locality
- implementation relationships
- operational context
- and workflow continuity
The filesystem is NOT treated as:
- a graph database
- an ontology tree
- or a semantic ownership hierarchy
The repository intentionally preserves real engineering structure.
The runtime preserves deterministic behavior.
The runtime is responsible for:
- normalization
- validation
- canonical serialization
- deterministic-safe editing
- and semantic consistency
The runtime intentionally owns:
structural correctness
rather than contextual reasoning.
The serializer preserves canonical structure.
The serializer is responsible for:
- normalized markdown structure
- metadata consistency
- deterministic formatting
- and serializer-safe transformations
This prevents:
- markdown drift
- structural fragmentation
- and semantic inconsistency
Skills operate as:
operational capabilities
A skill modifies:
- contextual reasoning
- workflow heuristics
- implementation awareness
- continuity behavior
- and operational interpretation
inside a workspace.
Skills intentionally DO NOT:
- mutate runtime semantics
- preserve invariants
- own repository structure
- or replace deterministic systems
Agents perform inference.
Agents are responsible for:
- contextual synthesis
- implementation reasoning
- workflow continuity
- operational interpretation
- and contextual recovery
The architecture intentionally keeps agents:
- bounded
- filesystem-aware
- implementation-grounded
- and operationally constrained
One of the strongest architectural conclusions became:
a skill represents
a distinct operational capability mode
NOT:
- a capability
- a command
- a taxonomy category
- a plugin
- or a philosophy fragment
This principle stabilizes:
- trigger behavior
- overlap handling
- operational coherence
- and contextual continuity
The architecture intentionally favors:
few dense operational overlays
rather than:
many fragmented conceptual overlays
The repository intentionally minimizes:
- micro-skills
- capability decomposition
- taxonomy inflation
- conceptual fragmentation
- and prompt overlap
This improves:
- operational stability
- token efficiency
- trigger precision
- and contextual continuity
The operational model prioritizes:
context should survive longer than a single AI session
The system is designed for workflows such as:
- debugging continuity
- implementation-aware handoffs
- architecture reconstruction
- unresolved state recovery
- and long-running feature development
across multiple sessions and tools.
The operational model intentionally prioritizes:
implementation-grounded operational continuity
Contextual reasoning remains tied to:
- source code
- runtime behavior
- implementation details
- operational workflows
- and repository locality
This fundamentally differentiates the system from:
- PKM systems
- graph-centric workflows
- semantic repositories
- and ontology-oriented tooling
Semantic participation remains intentionally bounded.
Recommended semantic root:
.context/notes
Only files inside semantic scope:
- participate in symbolic semantics
- support semantic navigation
- and participate in contextual reasoning
Files outside semantic scope remain:
- filesystem artifacts
- operational resources
- implementation context
- and external references
Core principle:
semantic scope != filesystem scope
Wikilinks operate as:
bounded symbolic contextual references
NOT:
- graph-authoritative edges
- ontology relationships
- semantic ownership structures
- or repository-global semantic primitives
The graph MAY emerge naturally from symbolic references.
The graph MUST remain secondary to:
- filesystem authority
- implementation locality
- and deterministic runtime behavior
Skills activate through contextual relevance.
Trigger behavior intentionally favors:
- contextual specificity
- operational density
- low overlap
- and bounded activation surfaces
The architecture intentionally avoids:
- broad conceptual triggers
- ontology-wide activation
- capability explosion
- and fragmented micro-skills
The operational model supports a shared filesystem-native skill surface.
Recommended convention:
.agents/skills
Optional namespaced layout:
.agents/skills/weave-skills
This convention intentionally remains:
- lightweight
- optional
- portable
- adapter-friendly
- and filesystem-native
Composition is intentionally handled through filesystem primitives.
Examples include:
- symbolic links
- junctions
- bind mounts
- aliases
- and shared filesystem mappings
This avoids:
- orchestration runtimes
- synchronization layers
- generated integration systems
- and duplicated runtime trees
The operational model intentionally favors long-running operational continuity inside real repositories.
The system prioritizes:
- workflow continuity
- contextual recovery
- operational traceability
- implementation grounding
- and deterministic-safe contextual reasoning
across long-running engineering workflows.