Persistent identity and state
A single Resident records append-only events, restores persisted state, and separates current context from colder history.
OBSERVED INTERNALLYIndependent AI research project from Brazil
DRENDA
Persistent Local Cognitive Architecture
Arquitetura Cognitiva Local Persistente
A research system for persistent identity, structured memory, causal goals, tool-mediated action, auditable experiments, and reversible capability evolution on ordinary local hardware.
Um sistema de pesquisa sobre identidade persistente, memória estruturada, objetivos causais, ação por ferramentas, experimentos auditáveis e evolução reversível de capacidades em hardware local comum.
THE CLAIM IS AN INVITATION TO VERIFYO CONVITE É VERIFICAR
Don't take my word for it. Test it.Não acredite em mim. Teste.
Choose a registered test, submit an allowed challenge, inspect the outcome and verify its proof—even when the result is a fail.
Escolha um teste registrado, envie um desafio permitido, veja o resultado e confira a prova—mesmo quando der FAIL.
Explore tests T01–T09Explorar testes T01–T09
Create your own T07 input/output challengeCriar seu desafio T07 de entrada/saída
How scientific evaluation works →Como funciona a avaliação científica →
Local ResidentObserved internally
Evidence ledgerHash-addressed artifacts
NÉFRONEngineering gate documented
Public evaluationSubmit a challenge and verify its proof
PUBLIC TEST CATALOGCATÁLOGO DE TESTES PÚBLICOS
Pick a question. Run the test. Check the proof.Escolha uma pergunta. Execute o teste. Confira a prova.
T01–T09 are one click away. Live tests are marked below; T05 and T06 currently link to their registered protocols because their submission options are not active.
T01–T09 estão a um clique. Os testes vivos estão marcados; T05 e T06 levam ao protocolo registrado porque suas submissões ainda não estão ativas.
- T01Goal continuityContinuidade de GoalLIVE
- T02Causal state controlsControles causais de estadoLIVE
- T03Learn, ablate, restoreAprender, ablar, restaurarLIVE
- T04Bounded tool creationCriação delimitada de ferramentaLIVE
- T05Cross-family compositionComposição entre famíliasPROTOCOL
- T06Text-to-numeric transferTransferência texto→numéricoPROTOCOL
- T07Your input/output challengeSeu desafio entrada/saídaLIVE
- T08Causal tool challengeDesafio causal de ferramentaLIVE
- T09Paired learning experimentExperimento de aprendizagem pareadaLIVE
Each test states what it measures. A running challenge, a signed receipt and an independently verified scientific conclusion are different things.
Cada teste declara o que mede. Desafio em execução, recibo assinado e conclusão científica independente são coisas diferentes.
What it is
A persistent AI architecture designed to learn, act and be examined.
DRENDA combines symbolic and procedural components, persistent state, evidence-aware memory, planners, evaluators and tool interfaces. It is not built around predicting the next word with a large language model. Its research focus is the causal path from experience and goals to testable new capabilities.
Goals, gaps, plans, actions
The architecture represents owner goals, capability gaps, questions, evidence, plans, experiments, results, and receipts as explicit causal objects.
REPRODUCIBLE ARTIFACTAuditable discovery process
Candidate, Judge, observation, inference and promotion have distinct roles. Each experiment can be inspected through its source identity, outcome and causal receipts.
OPEN TO REVIEWBuilt in Brazil
The DRENDA Matheus is building on his own computerA DRENDA que Matheus constrói no próprio computador
DRENDA is a working local research system, not just this website. One Resident maintains its identity and active Goals across process restarts. It connects persistent memory, goal execution, study, tools and experimental evaluation so that an observation can be traced to a later decision and tested capability.
A DRENDA é um sistema local de pesquisa em funcionamento, não apenas este site. Um único Resident preserva sua identidade e seus Goals ativos entre reinícios do processo. Ele conecta memória persistente, execução de metas, estudo, ferramentas e avaliação experimental para que uma observação possa ser rastreada até uma decisão posterior e uma capacidade testada.
A continuous operating loopUm ciclo operacional contínuo
The Resident keeps Goal identity, event history, active context and reusable capabilities in persisted state. Its work can be resumed and audited after a fresh-process restart.
O Resident mantém identidade dos Goals, histórico de eventos, contexto ativo e capacidades reutilizáveis em estado persistido. O trabalho pode ser retomado e auditado após reiniciar em outro processo.
Study, build and verifyEstudar, construir e verificar
DRENDA organizes questions, evidence, hypotheses, experiments and candidate capabilities. Specialized components include PARIETAL for mathematics, NÉFRON for engineering faults, and FORJA for isolated trials and causal controls.
A DRENDA organiza perguntas, evidências, hipóteses, experimentos e capacidades candidatas. Seus componentes especializados incluem PARIETAL para matemática, NÉFRON para falhas de engenharia e FORJA para ensaios isolados e controles causais.
Public tests with receiptsTestes públicos com recibos
The isolated public lab lists T01–T09, with the live availability of each test shown in the catalog above. Evaluators can submit allowed challenges, inspect measured outcomes, download proof bundles and check signatures and hashes offline. Each test states its own scope.
O laboratório público isolado lista T01–T09, com a disponibilidade de cada teste no catálogo acima. Avaliadores podem enviar desafios permitidos, inspecionar resultados medidos, baixar pacotes de prova e conferir assinaturas e hashes offline. Cada teste declara seu próprio escopo.
Open the evaluation labEvidence
Follow the experiments, not a slogan
Explore a public challenge, the documented local Resident, resource profile, engineering work and a causal D0 → D1 → D2 research case. Each link shows how that result was obtained.
| Experiment or observation | Evidence | How to inspect |
|---|---|---|
| Evaluator-supplied Goal survived a fresh-process restart | PUBLIC T01/T14 | Run your own challenge, inspect the Judge result and verify its signed proof offline. |
| Goal ablation, foreign-Goal and corruption controls, with exact restoration | PUBLIC T02 | Run the causal state-control battery; a baseline PASS alone is insufficient. |
| Learned experiment preference reused on new tasks; artifact ablation, restore and restart | PUBLIC T03 | Run the learning trial. Supervised program synthesis within the same four-feature grammar; inspect every holdout decision. |
| Single local Resident restored persistent state and reached its ready loop | CLAIM-002 | Read the sanitized event evidence. |
| D0 → D1 → D2 causal succession experiment | INTERNAL RESEARCH CASE | Inspect the freeze, holdout, ablation, restore and restart record. |
| Local hardware: Ryzen 7 5700, 23.9 GiB RAM, RX 580-class GPU | CLAIM-003 | Inspect measured host evidence. |
| NÉFRON engineering foundation and live observer | CLAIM-004 | Inspect implementation status. |
Causal case study
D0 → D1 → D2: did one acquired capability enable the next?
A September 2026 internal experiment compared D0 and D1 under the same 62 observations and budget. D0 did not yield an executable second candidate; D1 supplied an intermediate feature used to form D2. The record then tested 64 post-freeze cases, removed D1 and D2 separately, restored them and repeated checks after a process restart.
Equal-budget D0 / D1
Both versions received the same evidence budget. The second candidate referenced the previously validated D1 artifact by hash rather than embedding it.
Ablate → restore
Removing D1 prevented D2 execution; restoring D1 recovered it. Removing D2 removed its measured gain; restoring D2 recovered it.
Restart → transfer
The internal record reports post-restart retention and four longer-sequence transfer cases. An external evaluator can inspect the frozen identities and challenge this case independently.
This is a documented internal research case, distinct from the public VPS challenge. The claim, budget, authorship, measured outputs and constraints are in the case-study dossier; the original 64-case holdout remains unpublished to protect future evaluation design.
5-minute route
Run a challenge and verify the proof yourself
A public evaluation service accepts a fresh Goal, displays worker and Judge receipts and provides a signed proof that you can check independently.
LIVE CHALLENGE
Your Goal, fresh process, signed result
Bring a non-sensitive Goal of your own and inspect what the registered continuity test measures.
- Read the registered test contract.
- Submit your Goal to the public evaluation queue.
- Inspect worker/Judge receipts and result.
- Download the signed proof bundle.
- Verify the proof offline on another machine.
15-minute route
Inspect a causal chain, not a highlight reel
The deeper path checks persistence, plan authorship, evidence, consumer identity, limitations, and restart boundaries.
Architecture and provenance
Trace Goal → gap → question → evidence → plan → experiment contract, and identify which actor authored each object. Compare the documented Resident architecture with the public evaluator's registered test contract.
Run and independently verify
Submit a non-sensitive Goal, inspect the separate Judge receipt, download the proof and verify it with the Level 3 kit on a second machine. Record both successful and failed outcomes.
Public evaluation endpoint
Bring your own Goal. Inspect every receipt.
The public service accepts a new evaluator-written Goal, runs a frozen DRENDA state component in an isolated worker, restarts the process, then produces a separately signed proof. The test contract specifies exactly what the result measures.
Plain-text Goal only
The registered test accepts a short, non-sensitive Goal statement. It rejects unregistered tests and executable input.
Queue and Judge receipts
The public lab shows the challenge state and event receipts, and returns a signed result bundle.
Independent second machine
Download the Level 3 offline verifier kit. The second-machine run is still pending until an independent reviewer reports it.
Architecture
A persistent cognitive loop with explicit boundaries
The full system is larger than any isolated core file. Public materials distinguish the conceptual engine, operational runtime, accumulated state, and cold evidence.
Perception
Meaning
Goal / Gap
Plan
Action / Experiment
Evidence / Next decision
Resident and active context
Identity, active goals, recent memory, routing, and current obligations.
Capabilities and indexed memory
Reusable tools, representations, learned state, evaluation receipts, and searchable history.
Evidence and archives
Long history, reports, snapshots, discarded candidates, and reproducibility artifacts.
The architecture includes the operational runtime and memory tiers; it is larger than an isolated core file. The storage audit records the distinction.
NÉFRON
Engineering self-repair as a measurable loop
The engineering track records defects, executable repair candidates, separate validation, rollback and continuation of the originating Goal. The public dossier shows the foundation; deeper repair trials can be reviewed under an independent protocol.
Capture a real operational gap
Store the exact causal identity and evidence without rewriting the cognitive content.
Support reversible repair candidates
Keep proposed change, predicted effect, budget, rollback, and judge boundary explicit.
Adversarial repair trial
Freeze a new reproducible fault, conceal the repair, compare baseline and candidate, then ablate, restore and restart. Request a supervised independent run.
RESEARCH ACCESSIndependent validation
Designed to be challenged
An external evaluator should freeze the target, define post-freeze tests, constrain compute, verify provenance, ablate the claimed mechanism, restore it, restart the system, and publish negative as well as positive results.
Freeze
Hash code, state boundary, hardware, budget, evaluator, and test-generation time.
Falsify
Use hidden holdouts, negative controls, ablation, restore, restart, and distant-domain transfer.
Attribute
Separate owner instruction, external engineering, DRENDA-authored candidate, independent judge, and measured outcome.
Contact
Independent scrutiny is welcome.
The preferred next step is a scoped technical review of the public evidence pack, followed by a supervised isolated evaluation if the reviewer finds the architecture worth testing.
Matheus Silva
Independent creator, Brazil
No source transfer is required for an initial evidence review. Evaluation scope and confidentiality can be agreed before any live session.