PixieCoreTHE CORE OF PIXIEFLOW · DESIGN PHASE
GivePrompt-OrientedProgramming (POP)adependable core.
Small core. Explicit boundaries. Open extensions.
PixieCore is the small, explicit core for loading YAML Blueprints, executing them safely, validating structured output, and extending the runtime without changing it.
01THE BOUNDARY
Keep only the essentials
in the core.
PixieCore is not a big box that tries to do everything. It contains only the minimal contracts worth sharing over time, while fast-changing capabilities remain in extensions.
- Blueprint contract
- Execution lifecycle
- Structured-output validation
- Tool boundaries
- Audit and observability
- Model, OCR, and RAG integrations
- Domain-specific policies
- UI and distribution
- Capability plugins
- Experimental features
02ARCHITECTURE
Small layers.
Clear responsibilities.
Each layer has one job: declare the work, run it, connect capabilities, and grow without making the runtime opaque.
Extension contract
Add capabilities such as extractors, validators, translators, and retrievers without bloating the core.
Tool boundary
A controlled boundary for models, OCR, RAG, and external capabilities, with policy and traceability.
Execution model
Bind inputs to a Blueprint, execute, validate against schema, observe outcomes, and retry when needed.
Intent model
A versioned YAML Blueprint declaring roles, scenario, rules, examples, and an output schema.
PIXIECORE / PROPOSED MODEL
03CONTRACTS
Turn boundaries into
readable contracts.
The promises between components outlive their internal implementations. PixieCore avoids implicit coupling by making entry points, execution, and extension explicit.
Intent contract
A Blueprint declares the role, scenario, rules, examples, and the output the workflow must produce.
ROLE / SCENARIO / SCHEMAExecution contract
Inputs become a rendered prompt; the runtime executes, validates structured output, and records the result.
INPUT / EXECUTE / VALIDATEExtension contract
Capabilities connect through explicit hooks and policy boundaries, without changing the core runtime.
CAPABILITY / POLICY / LIFECYCLE04LIFECYCLE
It does not end with
one generation.
Describe, compose, execute, observe, and refine. PixieCore treats that cycle as one consistent model.
- 01Describe
- 02Compose
- 03Execute
- 04Observe
- 05Refine
05STATUS
Design phase
From blueprint
to implementation.
We start by defining stable boundaries without promising versions or APIs that do not yet exist.
01Core principlesIN PROGRESS
02Execution modelNEXT
03Reference implementationPLANNED
04Extension contractPLANNED
DOCUMENTATION & REPOSITORY