# Aura publishes its null result on the front page and its own gap list

> A local agent research project on Apple Silicon, with verifier-graded LoRA training and a hash-chained ledger of receipts. Its most useful pages are the ones listing what it has not proven, including claim 31, where it concedes a simpler computer-use agent does the demo tasks.

**youngbryan97/aura** — A cognitive architecture that runs on your own machine. Internal state reaches generation through the model's activations, not the system prompt — and every consequential action leaves a receipt you can audit. Not an assistant. IIT 4.0 φ, CAA steering, 136 consciousness modules, local on Apple Silicon.

- Repository: https://github.com/youngbryan97/aura
- Stars: 130 · Forks: 25
- Language: Python
- License: NOASSERTION
- Published: 2026-08-24 · Updated: 2026-08-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/youngbryan97-aura

## The front page leads with an experiment that did not work

The headline of this repository is a null result, and that placement is the first thing to notice. `docs/RECURSIVE_LATENT_CORTEX.md` is named as the main research program, and the question it asks is whether a frozen 32-billion-parameter model can be made to reason deeper without changing any of its stored weights. The project built machinery to test that, ran a pre-registered experiment, and reports that the hoped-for capability improvement did not appear.

Most repositories lead with what works. This one puts the failure above the install instructions and calls the rest a smaller, testable claim: internal state measurably affects what it generates, what it remembers, which tools it may use, what tasks it picks up on its own, and how it repairs itself, through code paths that leave audit trails you can inspect.

The framing is repeated twice more before the install. Aura is not proof of consciousness, life or personhood. And some file and module names sound as though they might be, but they are named after the mechanisms they implement rather than achievements they have proven.

## make setup, then make demo-learning, on the Mac named in the README

The first runnable thing on the page takes two commands, on Apple Silicon, in 20 to 40 minutes, using about 5 GB of disk:

```bash
make setup          # once: venv + requirements
make demo-learning
```

The sequence it walks through is worth following closely, because each step is a gate. A small local model attempts seeded reasoning tasks. Every attempt is graded by an exact checker, and the verifier is the reward signal, so there is nothing to game. The verified wins and losses then train a LoRA adapter. That adapter has to pass a sealed held-out test set on fresh inputs it has never seen before its weights are merged and published. Then it runs the whole thing again, building on what it just published.

So publication is not a step in the training loop, it is the exit condition for it. An adapter that improves on the training tasks but fails the sealed set never reaches the weights, which is the mechanism that separates this from a loop that optimises its own reward.

`INSTALL.md` and `HARDWARE_PROFILES.md` are the two pages to read before this, given the hardware constraint described further down.

## The verdict comes from a hash-chained ledger, and a refusal prints as loudly as a gain

Every generation is recorded in a hash-chained ledger at `core/learning/rsi_lineage.py`, and the verdict is computed from those receipts rather than written by hand afterwards. When the loop refuses to promote an adapter, that prints just as loudly as a gain. Raw responses, evaluation reports and cycle receipts stay on disk, and the same machinery runs autonomously inside the live runtime.

The evidence rules are unusually strict for a README. Claims are supposed to point at runnable tests, proof bundles, receipts or replayable logs. And the page tells you not to trust its own numbers: test counts change with the repository, so use `pytest --collect-only`, `make proof-bundle` and `TESTING.md` for current figures.

The boundary is enforced in code rather than promised in prose. A guard treats loaded terms such as "consciousness guarantee" and "personhood proof" as names for test batteries rather than claims, unless independent evidence says otherwise, and the page states the principle flatly about a specific file: `qualia_synthesizer.py` is a name, and names are not evidence.

## Claim 31 is the page that says the cognitive layer has not earned its cost

Two components have been measured against simpler alternatives under matched budgets, and they are the whole of the positive evidence for the memory layer. Claim 31a: memory retrieval beats a basic context window when the needed fact falls outside the window. Claim 31b: the revision gate beats both "always keep the first answer" and "always keep the second" over the same two generations.

Then the same paragraph dismantles the rest. Two subsystems on two task types is not the whole layer. Nothing yet shows that the IIT metrics, the qualia modules, the neurochemical simulation, the substrate differential equations, the dream cycles or the theory arbitration make the system better at a task a user wants done. The alternative is named in the same breath: a far simpler computer-use agent performs the demo tasks without any of them.

The costs are then itemised: latency, memory, tuning surface, and failure modes the project says it has repeatedly paid for. The closing line of that section is the one to remember. Complexity is justified by measured advantage, and most of it has not been measured. See `CLAIMS_MATRIX.md` claim 31.

## The hardware target is one Mac with 64 GB, and the pins agree

The hardware section names a specific machine rather than a class: an Apple Silicon M5-class Mac with 64 GB of unified memory. Lower-memory machines downshift their model lanes, they do not get the same performance, and the page is explicit that claiming otherwise would be benchmarking on hardware nobody has.

The dependency pins say the same thing from the other direction. `mlx` is held at `0.32.0` for native allocator and lifetime fixes, `mlx-lm` at `0.31.3` as the resident 32B runtime contract, and `mlx-lm-lora` at `2.1.0` as the DPO, ORPO and GRPO trainer bridge for verifier rewards. `faiss-cpu` is annotated as unified memory friendly. These are Apple Silicon dependencies by construction, not by preference.

Resource cost is treated as a first-class constraint rather than an afterthought, described as a practical analog to biological metabolism and immediately qualified with the sentence that it is not biological metabolism. The same section lists what stays outside the evidence scope: autonomous self-improvement, where the scaffolding for repair, evaluation, patch tracking and proof bundles exists but a result does not, and unverified self-modification, which stays out until long real-world runs, hidden external tasks and independent replication all succeed.

## φ is bounded, and steering is causal but not yet clean

Three claims about internals are made with the same discipline, and all three come with a stated limit.

φ, phi, is a bounded integration metric inspired by Integrated Information Theory, computed over tractable subsystems. It is not a whole-system consciousness measurement, and the page says full-system IIT is computationally intractable and that this project did not solve it.

Emotional steering is described as causal and therefore testable: internal state reaches text generation through non-text channels, using Contrastive Activation Addition, a technique that modifies the model's hidden computations directly rather than the prompt. The limit is admitted in the next breath. Black-box steering tests can hide live emotional telemetry from the prompt text, and strong adversarial baselines are required before the result counts. A mechanism that reaches generation is not the same as a measurement that can see it.

Identity persistence, the third, uses retrieval rather than prompt anchoring alone, maintained by ID-RAG Chronicle retrieval. Governance is handled the same way, as a design goal rather than a guaranteed fact, where a lint failure, a direct tool fallback or a default-approved gateway is stated to be a bug.

## The container cannot install the dependencies the Mac needs

The Dockerfile explains its own constraint in comments rather than hiding it. It copies `requirements/core.txt` and `requirements/lock/container-constraints.txt` under a heading that reads fail-closed, no fallback installs. The comment underneath says the release lock constrains the install without being the install list, and that the difference is recorded rather than papered over.

The reason is named next. The macOS lock file was compiled on macOS and carries mlx and pyobjc with no environment markers, so it cannot install inside the container at all, and it has never resolved seven of the distributions that `requirements/core.txt` asks for. So there are two dependency sets by design, one for a machine with Apple Silicon and one for a Linux image, and the boundary between them is a hardware boundary rather than a packaging preference.

The header of the same file gives the three commands it expects to be used with: build the image, run it with port 8000 mapped and an `aura-data` volume at `/app/data`, then verify with `make doctor` inside a throwaway container. The image is labelled with a maintainer address at `security@aura-project.dev` and, notably, an explicit licence value of `NONE`.

## docker-compose.yml sets three environment variables that no Python reads

The compose file carries its own correction in a comment. `AURA_MODE` is the posture the runtime actually reads, at `core/runtime/mode.py`. `AURA_ENV`, `AURA_HOST` and `AURA_PORT` were set there and no Python reads any of them. The port that matters comes from the `--port` default of 8000 in `aura_main`, which is what the port mapping and the healthcheck both assume. The healthcheck itself is a Python one-liner hitting `http://127.0.0.1:8000/api/health` every 30 seconds with a 5 second timeout and 3 retries.

Two services in the stack deserve a second look given the project's framing. There is a `redis-broker` on `redis:alpine`, and a `celery-worker` running `celery -A core.tasks worker --loglevel=info` with `AURA_MODE=production`. A task queue and a broker are a multi-process deployment shape, which sits oddly beside a project whose main claim is that it runs on your Mac.

What is genuinely careful here is the network exposure. Both published ports are bound to `127.0.0.1`, redis on 6379 and the API on 8000, and the API service also carries `AURA_INTERNAL_ONLY=1`. The production posture flag is set in both services.

## Conclusion

Aura fits a reader who wants to see an agent research project describe its own evidence standard and apply it against itself, and a Mac owner with 64 GB of unified memory who will spend 20 to 40 minutes and about 5 GB of disk to watch a verified training loop run. It does not fit anyone wanting a production agent, which the project rules out itself, and it is not portable: the container build cannot install the mlx and pyobjc set that the macOS requirements carry. Verify three things before believing a claim here: whether it points at a runnable test rather than at prose, whether the test counts on the page are older than `pytest --collect-only`, and whether the 27 top-level markdown files include a `CLAIMS_NOT_SUPPORTED.md` you have read. The last push was on 2026-09-25, no GitHub releases exist, and no licence is recorded for the repository.

## FAQ

### What does running make demo-learning in Aura actually do?

A small local model attempts seeded reasoning tasks, every attempt is graded by an exact checker that is itself the reward signal, and a LoRA adapter trains on the verified wins and losses. The adapter must pass a sealed held-out test set on fresh inputs before its weights are merged and published, and the loop then repeats.

### What hardware does Aura need to run?

An Apple Silicon M5-class Mac with 64 GB of unified memory is the stated target. Lower-memory machines downshift their model lanes and do not get the same performance, and the project says claiming otherwise would be benchmarking on hardware nobody has.

### Does Aura claim to have proven consciousness or personhood?

No. The page states plainly that it is not proof of consciousness, life or personhood, that module names are named after mechanisms rather than achievements, and that phi is a bounded metric over tractable subsystems rather than a whole-system measurement.

### Can Aura be deployed with Docker?

There is a Dockerfile and a compose file with redis-broker, celery-worker and aura services. The Dockerfile copies requirements/core.txt under a fail-closed heading, because the macOS lock carries mlx and pyobjc with no environment markers and cannot install in a Linux image.

### How does Aura compute the verdict on a trained adapter?

Every generation is recorded in a hash-chained ledger at core/learning/rsi_lineage.py and the verdict is computed from those receipts rather than written by hand. A refusal to promote prints as loudly as a gain, and raw responses, evaluation reports and cycle receipts stay on disk.

## Sources

- [Official README](https://github.com/youngbryan97/aura#readme)
- [Project repository](https://github.com/youngbryan97/aura)
- [README](https://github.com/youngbryan97/aura/blob/main/README.md)
- [Releases](https://github.com/youngbryan97/aura/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/youngbryan97-aura