Your knowledge, concepts, experience, and intuition are the foundation of Akasha.
Akasha is not designed to replace expertise.
It is designed to help experts:
- structure knowledge,
- preserve meaning,
- build reusable thinking systems,
- and transform their concepts into living tools.
You are the main actor in the design process.
The LLM helps translate your thinking into structure and code.
As a result, Akasha can quickly become:
- a research assistant,
- a thinking partner,
- a worldbuilding system,
- a scientific notebook,
- a strategic memory,
- or a long-term knowledge environment.
Akasha is a concept-oriented operating system — a persistent semantic environment where you can handle concepts and Concept Models with the same freedom and fluency that an operating system gives you over files and processes.
Most software stores:
- files,
- documents,
- tables,
- or messages.
Akasha stores:
- atoms (content-addressed nodes) and typed links,
- interpretations and judgments,
- states and state changes,
- events,
- and evolving structures of thought.
Instead of asking:
"How should this data be stored?"
Akasha asks:
"What kind of thing is this?"
That question leads to a Concept Model.
A Concept Model is a structured way of representing a meaningful human activity.
| Human activity | Concept Model | CLI prefix |
|---|---|---|
| Writing ideas | Note (note.*) |
n. |
| Recording observations | FieldNote (fieldnote.*) |
fn. |
| Collecting responses | Survey (survey.*) |
sv. |
| Finding patterns | Aggregation (agg.*) |
ag. |
| Building interpretations | Synthesis (synth.*) |
sy. |
| Managing persistent fictional state | World (world.*) |
wd. |
| Modeling identity / persona | Cast (cast.*) |
cs. |
| Structured data from any source | Record (rec.*) |
rec. |
| Navigating semantic vocabulary | Thesaurus (thesaurus.*) |
thesaurus. |
A Concept Model is not a file type.
It is:
- a way of organizing meaning,
- a way of preserving relationships,
- and a way of representing change over time.
The same Atoms can be viewed simultaneously through multiple Concept Models — as a navigation node, a data record, and a point on a scatter plot — without any duplication of data.
Every action in Akasha is governed by a single organizing principle:
Operand — data. An Atom carries no behaviour. It is content-addressed text with no methods.
Operator — operation. Defined independently of the data it transforms. A rec.table operator reads attribute links from any atom set and renders a table. It does not care how the atoms were created.
Agent — subject. Applies operators to operands. An agent may be a human typing in a terminal, an LLM, a sensor, or an automated script. The operator does not know or care which.
This is deliberately different from object-oriented design, where behaviour is embedded inside data objects. When behaviour needs to change in OO, the object changes — or requires inheritance, wrapping, or design patterns to work around the coupling.
Akasha does not do this.
Adding a new operator is a new class file. Atoms remain immutable. Agents can apply any operator they are authorized for.
This principle governs every layer of Akasha — from graph primitives up through Concept Models, session access control, and LLM integration. When you design a Concept Model, you are designing operators that act on atoms. The atoms know nothing about the operators, and the operators know nothing about who or what is calling them.
One of the core ideas behind Akasha is:
Domain experts should be able to design systems directly.
You do not need to:
- design databases,
- write backend architectures,
- manage storage engines,
- or build frameworks.
Instead, you describe:
- the concepts,
- the relationships,
- the actions,
- and the meanings.
The LLM can then help generate:
- Concept Models,
- operators,
- structures,
- links,
- and implementation code.
Akasha bridges expert thinking and executable systems.
Do not begin with technology.
Begin with the real activity.
Ask: "What is actually happening here?"
Examples:
A historian may say:
"I compare interpretations across sources."
A biologist may say:
"I observe changes in field conditions over time."
A game designer may say:
"Events permanently alter political regions."
A strategist may say:
"Claims must be traceable back to evidence."
These are not database problems.
They are conceptual structures.
A good Concept Model should feel obvious to the expert using it.
Operations should resemble meaningful actions.
Good (example syntax — illustrates intent, not exact CLI form):
world.event "The king died"
world.place.state castle succession_crisis
survey.new name=field_survey_2024
survey.q.add name=... question="How would you rate...?"
rec.new type=observation content="Dense canopy cover"
rec.set key=... attr=biodiversity_index val=0.87
Bad:
insert_node
append_blob
create_row
The system should reflect human reasoning, not implementation mechanics.
One of the most practical expressions of Akasha's design is the lens scanner.
lens projects any source — an existing set, an ontology subtree, a traversal result — into a structured Concept Model view. It discovers the attributes already present on each atom from their links. You do not declare a schema first.
# Scan the built-in fruits set — sweetness/acidity attributes already in the ontology
lens src=set:fruits
# Project the scan into a record set
lens.flatten into=fruit_view
# Display as a formatted table
rec.table in_set=set:fruit_view
# Project onto a 4-quadrant scatter plot — no browser required
quadrant.plot in_set=set:fruit_view \
x=acidity y=sweetness \
q1="tangy sweet" q2="mellow sweet" \
q3="bland" q4="sharp"
You can also add analytical attributes to atoms that already exist in the graph, without touching their structure:
# Annotate existing ontology atoms with a rec: attribute link
rec.set key=concept:aristotle attr=influence_score val=0.95
rec.set key=concept:heraclitus attr=influence_score val=0.88
rec.idx key=concept:aristotle sets=rec:philosophers
rec.idx key=concept:heraclitus sets=rec:philosophers
# The original atoms are untouched — only rec: links were added
rec.table in_set=set:rec:philosophers
This is the Operand/Operator/Agent principle in practice: atoms are untouched data, rec.* operators act on them from outside, and you are the agent deciding what to measure.
Akasha separates content from structure.
For example:
A Record model does not contain the research itself.
It contains:
- attributes,
- measurements,
- computed positions,
- and analytical projections.
Likewise:
- a Synthesis references evidence,
- a World records state changes,
- a Cast maintains identity structure,
- an Aggregation organizes measurements.
This allows:
- reinterpretation,
- reuse,
- multiple perspectives,
- long-term evolution.
One of the most powerful ideas in Akasha is the World model.
A World is not merely lore, geography, or story text.
It is a persistent state system.
For example (example syntax — illustrates intent):
world.event "The king died"
creates a recorded event. But humans decide the consequences:
world.place.state castle succession_crisis
world.law.change royal_succession destabilized
This distinction is intentional.
Akasha separates recording an event from interpreting its effects.
Meaning remains under human control.
In Akasha, the LLM is not the author of meaning.
The human expert remains the source of:
- interpretation,
- intuition,
- judgment,
- and conceptual understanding.
The LLM helps by:
- generating structures,
- proposing operators,
- organizing relationships,
- writing implementation code,
- generating
.akontology files and Concept Model classes, - and accelerating iteration.
This changes software development fundamentally.
Experts can directly shape systems around their own thinking.
A useful starting process:
What are people actually doing?
Examples: observing, comparing, classifying, arguing, narrating, planning, simulating.
What continues to exist over time?
Examples: events, places, actors, claims, observations, measurements, regions, themes.
What connections matter?
Examples: supports, contradicts, occurred_at, belongs_to, derived_from, affects, references.
What operations should exist?
Examples: add observation, record event, attach evidence, create interpretation, update world state.
Do not model the entire universe at once.
Small models combine better.
Good systems emerge from relationships between models, not from giant monolithic structures.
One of the greatest risks when building systems with LLMs is something often called "vibe programming".
This happens when:
- code is generated quickly,
- structures appear convincing,
- everything feels productive, but
- the conceptual foundations are unclear.
The result is usually:
- fragile systems,
- inconsistent abstractions,
- accidental complexity,
- and architectures nobody truly understands.
Akasha was designed specifically to avoid this problem.
The LLM should generate implementation. The human should define meaning.
This distinction is critical.
The expert decides:
- what concepts exist,
- what relationships matter,
- what changes over time,
- and what operations are meaningful.
The LLM helps:
- formalize structure,
- write repetitive code,
- propose patterns,
- accelerate iteration,
- and explore alternatives.
But the conceptual direction must remain human-led.
"Build me an AI research system."
The LLM invents structures, terminology, operations, storage assumptions, and workflows.
The human only reacts afterward.
This often creates systems that feel impressive, but do not actually match real expert practice.
The human first explains:
"In my research process, I:
- collect observations,
- compare interpretations,
- group evidence,
- build claims,
- and trace arguments back to sources."
Now the LLM has conceptual grounding. It can help propose:
- FieldNote,
- Aggregation,
- Synthesis,
- evidence links,
- reasoning traces,
- and operator structures.
The expert remains the source of meaning.
LLMs are extremely effective at:
- converting conceptual descriptions into structure,
- generating repetitive implementation code,
- maintaining naming consistency,
- drafting operators,
- generating
.akontology files in bulk, - and extending existing patterns.
They are much weaker at:
- deciding what matters,
- understanding long-term conceptual stability,
- distinguishing deep structure from temporary fashion,
- or identifying the real cognitive workflow of experts.
That part remains human work.
A useful warning sign:
If the concept cannot yet be explained in plain language, the model is probably not ready to implement.
Before writing code, try describing — without technical terminology — what exists, what changes, and what actions matter.
Good:
- "Events permanently change world state."
- "Claims must be traceable to evidence."
- "Every observation needs a location and a timestamp."
Bad:
- "We need distributed semantic graph orchestration."
- "This creates generalized multi-agent ontological synergy."
If the explanation sounds like marketing language, the conceptual structure is probably unclear.
Another common mistake is asking the LLM to generate massive unified systems immediately.
"Create a complete research/worldbuilding/memory/intelligence platform."
This usually creates confused abstractions, duplicated concepts, unstable operator naming, and tangled semantics.
Instead: build one Concept Model at a time.
Good progression:
- Field observations
- Interpretation layer
- Evidence tracing
- Presentation layer
- Persistent world state
Small conceptual systems compose better than giant systems.
Another dangerous pattern:
event → AI automatically rewrites entire world state
This often creates opaque logic, unstable semantics, unpredictable outcomes, and loss of expert control.
Akasha intentionally prefers:
event recorded
→ human interprets consequences
→ explicit state updates recorded separately
# example syntax
world.event "The king died"
world.place.state castle succession_crisis
world.law.change succession destabilized
This preserves traceability, interpretability, and human judgment.
Automation can come later. Meaning should come first.
The most effective workflow is conversational iteration.
The human says:
- "This structure feels wrong."
- "These concepts should be separated."
- "This operation does not match real practice."
- "This relationship should be directional."
- "This should be persistent state, not an event."
The LLM then revises structure.
This works extremely well because:
- the human provides semantic intuition,
- the LLM provides structural acceleration.
Together they become a powerful design loop.
Whenever possible, use terminology already natural to the domain experts.
Researchers naturally say: observation, interpretation, claim, evidence.
Writers naturally say: character, faction, event, region.
Strategists naturally say: scenario, assessment, actor, influence.
Good Concept Models preserve the language people already think in.
Avoid inventing unnecessary technical vocabulary.
Fast code generation is not the true advantage.
The true advantage is:
Experts can now directly shape software around their own conceptual structures.
That changes the relationship between expertise, software, and implementation.
The system becomes:
- closer to real practice,
- easier to evolve,
- and more aligned with human reasoning.
Traditional software often assumes fixed schemas, fixed workflows, fixed meanings.
But real expertise evolves.
Akasha is designed for:
- evolving interpretations,
- changing structures,
- long-term reasoning,
- and accumulated semantic history.
It is designed for living knowledge.
Akasha can be used for far more than note-taking.
Research & Academia
qualitative research · field observation systems · literature synthesis · argument tracing · longitudinal studies · interdisciplinary knowledge mapping · citation reasoning systems · historical interpretation tracking · comparative philosophy archives
Science & Engineering
laboratory notebooks · systems analysis · experiment tracking · scientific interpretation graphs · simulation state recording · engineering design rationale tracking · failure analysis systems · research memory environments
Strategy & Intelligence
geopolitical modeling · strategic assessment · evidence chains · scenario analysis · organizational memory · institutional reasoning archives · policy evolution tracing · conflict simulation systems
Creative Work
worldbuilding · narrative state tracking · persistent lore systems · character psychology modeling · timeline management · faction relationship systems · dynamic setting evolution · historical fiction continuity systems
Education
concept learning maps · curriculum structures · reasoning visualization · collaborative interpretation systems · seminar knowledge environments · reflective learning archives
Business & Operations
institutional memory · decision traceability · policy evolution tracking · operational knowledge systems · meeting intelligence systems · product reasoning archives · organizational context preservation
AI & Cognitive Systems
agent memory architectures · persona systems · semantic environments · long-term contextual memory · reflective reasoning systems · multi-agent knowledge spaces · persistent AI world state systems
Personal Knowledge
research journals · life event mapping · reflective thinking systems · personal semantic archives · evolving knowledge gardens · autobiographical memory systems · idea development environments
Government & Society
legal interpretation tracking · public policy memory systems · legislative reasoning archives · cultural preservation systems · civic deliberation environments
Health & Care
longitudinal care observations · patient narrative systems · therapeutic reflection archives · behavioral pattern mapping · interdisciplinary care coordination memory
The easiest way to understand Akasha is not to read theory for three weeks.
It is to build something small.
The Cookbook is organized into three tracks — not by skill level, but by what you actually want to do:
🔴 Red — CLI Track · docs/cookbook/red/
For non-programmers. No code required.
Everything achievable with CLI commands alone — atoms, links, sets, concept models, scatter plots, lens scanning. If you are a researcher, writer, or analyst who wants to think in Akasha without writing Python or JavaScript, start here.
| Chapter | What you build |
|---|---|
| 0 — Basic Operations | Atoms, links, sets, aliases, navigation |
| 1 — Concept Models | Records, tables, scatter plots, lens scanning from the shell |
🔵 Blue — Programmer Track · docs/cookbook/blue/
For developers. Web interfaces and Python extensions.
Build your own browser application over Akasha's JSON-RPC API, then extend the concept model system in Python. A single HTML file is all it takes to create a custom view of your data.
| Chapter | What you build |
|---|---|
| 0 — Basic Operations | Web interface via POST /rpc; fetch() in plain JS; guest sessions |
| 1 — Concept Models | Custom concept model class in Python; BaseConcept API; TextViewConcept |
🟢 Green — Ontology Track · docs/cookbook/green/
For ontology builders. .ak files and LLM-assisted data.
Design namespaces, write .ak batch files, and enrich the built-in ontology with domain knowledge. LLMs generate .ak content in bulk; you review, refine, and load.
| Chapter | What you build |
|---|---|
| 0 — Basic Operations | .ak files: def, ln, al, set.add (.ak primitive; CLI uses s.add); namespace design; loading and verification |
| 1 — Concept Models | Ontology enrichment with rec: attributes; LLM-assisted attribute generation |
The important idea is this:
You do not need to become a full-time software engineer before building useful systems.
Small conceptual tools compound surprisingly quickly.
One semantic workflow becomes a notebook.
A notebook becomes a Concept Model.
A Concept Model becomes a living knowledge environment.
That is how Akasha grows.
It is an attempt to build systems that preserve:
- meaning,
- interpretation,
- expertise,
- and human conceptual structure over time.
The purpose is not only to store information.
The purpose is to help humans:
- think,
- remember,
- interpret,
- collaborate,
- and build knowledge systems that continue to evolve.
→ Back to README · Quick Start · Ontology Reference · Concept Model Spec