Contorium is a local-first system that introduces persistent project cognition into AI-assisted development workflows.
Instead of treating AI as a tool that operates on code, Contorium treats the project itself as a structured, evolving system.
⸻
🧠 Problem
Modern AI coding workflows suffer from a structural limitation:
Even with tools like:
- Cursor
- Claude Code
- MCP-based agents
- IDE copilots
context is still:
- fragmented
- session-based
- non-persistent
- weakly structured
This leads to:
repeated explanations, lost reasoning, and architectural drift
⸻
🧩 Solution: Project Cognitive Runtime (PCR)
Contorium introduces a runtime model where project understanding is persistent and structured.
⸻
Core Components
⸻
- PIK — Project Intent Kernel
PIK defines the system-level intent of a project:
- primary goal
- constraints
- non-goals
- priority weighting
It acts as a stable semantic anchor.
⸻
- CIL — Cognitive Interaction Layer
CIL captures reasoning:
- why decisions were made
- what alternatives were considered
- how context influenced outcomes
It makes reasoning persistent instead of ephemeral.
⸻
- Timeline Layer
All system changes are recorded as events:
- code changes
- AI outputs
- tool interactions
- architectural decisions
This enables replay and evolution tracking.
⸻
- Drift Detection Layer
A continuous alignment system compares:
current behavior vs PIK intent
It detects:
- intent drift
- structural drift
- behavioral drift
And produces measurable deviation signals.
⸻
🔁 System Loop
Contorium forms a continuous loop:
- PIK defines intent
- Execution produces behavior
- Timeline records evolution
- Drift system evaluates alignment
- Suggestions guide correction
This creates a self-regulating project system.
⸻
🧠 Key Insight
Contorium is not an AI coding tool.
It is a:
Project Cognitive Runtime (PCR)
A system where software projects maintain structured intelligence over time.
⸻
🚀 Why it matters
The bottleneck in AI development is no longer capability.
It is continuity of understanding across:
- time
- tools
- agents
- sessions
Contorium is designed to address exactly that layer.
Top comments (6)
Persistent project cognition is valuable only if it has decay rules. I would want the runtime to remember decisions, but also mark when a decision is old, contradicted by code, or missing an owner. Otherwise memory slowly turns from context into stale authority.
That’s an excellent point.
I completely agree that persistent cognition shouldn’t mean permanent truth.
One direction I’m exploring is treating project knowledge as living intelligence rather than static memory.
Decisions should have signals such as:
• confidence
• last verified
• superseded by newer decisions
• consistency with the current codebase
• ownership when available
The goal isn’t to preserve history forever, but to preserve its validity over time.
I think “memory with decay” is much closer to real project cognition than immutable memory.
Yes, that distinction between history and validity is the key.
The part I would add is an explicit invalidation path: not only "last verified", but what kind of event should force re-checking it. Code change, owner change, dependency removal, and failed assumption are very different decay triggers.
Your point reveals a missing layer in our current lifecycle model. We already track confidence and freshness, but we need to model the causes of decay. I’m considering adding an invalidation engine that treats code changes, dependency changes, ownership changes, and broken assumptions as explicit validity signals rather than passive metadata.
That invalidation layer sounds like the right next abstraction. Freshness alone says the memory is old; cause-of-decay says whether it is still safe to use. Code changes, ownership changes, and dependency changes are exactly the signals that should make an agent slow down.
After reviewing our current lifecycle model, I think we already have the invalidation layer at the signal level (code, dependency, ownership, assumption failure).
The missing piece is not detecting decay events, but understanding which decisions are affected by those events.
Currently:
Event → Signal → Decision validity
The next abstraction should be:
Decision → Assumptions → Dependencies/Modules → Change Events → Impacted Decisions
This would allow Contorium to answer not only “this decision may be invalid”, but also “this decision became risky because assumption X changed due to event Y”.
I think this is the bridge from lifecycle tracking to decision intelligence.