Platform
Start from the problem
| You need | Start with |
|---|---|
| Persistent recurrent state and fixed-vector outputs | Sync runtime |
| Asynchronous spikes, delays or controlled temporal experiments | DPSH runtime |
| Token sequences and generated text | Transformer runtime |
| Exact execution of known algebraic dependencies | Levelized CDCT |
| Functional discovery and compilation of reusable algebraic structure | CDCT v1 |
| Explicit storage and retrieval | Memory engine |
| Several engines in one application | Orchestration layer |
ONNX inference is planned and remains unavailable. It is shown in the platform map so designs do not accidentally depend on an absent component.
One platform, explicit boundaries
Cognia separates computation from operation. Memory stores and retrieves. Orchestration connects typed components. Placement checks whether a deployment fits available resources. Learning manages training runs and promotion. Monitoring exposes bounded telemetry, while the desktop client presents that telemetry to an operator.
These layers do not change the mathematics of an engine. A capability verified for one runtime is never implied for another.
Evidence before claims
The project publishes validation gates, controlled experiments, limitations and negative results. “Implemented” means code exists. “Stable” describes an interface and its validation. “Accepted”, “rejected” and “inconclusive” describe research evidence. None of these labels is a claim of machine consciousness or general intelligence.
Explore
- Platform — understand the components and their boundaries.
- Build — move from a task to a verified application.
- Examples — start from a source-free runnable project.
- Research — inspect hypotheses, controls and outcomes.
- Releases — obtain a versioned, verified package.
- Pilot — define a measurable evaluation against a baseline.