001 / PERSONAL INTELLIGENCE
TESTEDA fresh chat. The same memory.
- Memory architecture
- Retrieval
- Recovery
30 September 2026
Open case study ↗- Problem
- Useful context was scattered across conversations and tied to whichever AI held the chat.
- My design choice
- Give memory its own record outside the chat. Keep the source and corrections with it, then prove a new session can recover it.
- What I built
- Independent, event-based memory with source records, decisions, corrections and explicit inference labels.
- How it works
- Selected records are saved outside the AI provider. A fresh authorised controller retrieves relevant context; a local cache can be rebuilt from the canonical copy.
- Verification
- A real private decision was saved through the remote controller, read back from Drive, restored into a temporary fresh cache and retrieved by a separate controller process.
- Limitations
- Sensitive records are excluded by default. Controllers must actively capture meaningful changes. This is not automatic recording of every conversation.
- What I learned
- Continuity depends on attribution and recovery, not the length of a chat window.
002 / PERSONAL INTELLIGENCE
TESTEDWork that outlasts a conversation.
- Workflow design
- Durable state
- Acceptance testing
30 September 2026
Open case study ↗- Problem
- Waiting for one long task should not monopolise the conversation.
- My design choice
- Let a persistent worker own the job. The conversation gets a receipt and stays free; the result belongs to the system.
- What I built
- A durable asynchronous queue, independent worker and saved job results.
- How it works
- The controller submits bounded work and gets a receipt. The service owns execution, checkpoints and the result. A later session can retrieve it.
- Verification
- A five-second diagnostic was submitted in 78 ms. An unrelated query returned in 68 ms while the job was running. It completed, and a fresh remote process retrieved the result. These are on-device call timings.
- Limitations
- The machine must be awake and connected. Jobs can wait behind other work. A diagnostic verifies the queue, not a production workload or a guaranteed completion time.
- What I learned
- A durable job needs a clear owner and recoverable output; it does not need a permanent conversational agent.
003 / PERSONAL INTELLIGENCE
TESTEDA controller you can replace.
- System architecture
- Model and tool integration
- Authority boundaries
30 September 2026
- Problem
- Changing an AI provider should not mean starting a personal system again.
- My design choice
- Put a small, shared tool interface between the AI and the system. Test each attachment without tying the memory to it.
- What I built
- A bounded controller interface for context, jobs, results and attributed writeback.
- How it works
- The AI asks the system for selected context and uses narrow tools. The tested ChatGPT route uses local Hermes / Remote Desktop; direct hosted attachment remains unverified.
- Verification
- The application suite passed 32 tests, including controller flows. Fresh controller processes also passed context retrieval, search, job submission, result retrieval and source-attributed writeback.
- Limitations
- Hosted direct MCP connections for ChatGPT, Grok and Gemini remain unverified. The broader computer-admin connection is a separate permission boundary.
- What I learned
- A shared interface makes replacement possible; each provider attachment still needs its own acceptance test.
004 / PERSONAL INTELLIGENCE
TESTEDUse a small model. Know when to stop.
- Model coordination
- Cost control
- Evaluation
30 September 2026
- Problem
- Routine work should not need an expensive model, but cheap answers are not automatically reliable.
- My design choice
- Keep repeatable collection in code. Use a local model for bounded tasks and return uncertain work for review instead of accepting a confident answer.
- What I built
- A local reasoning adapter, evidence limits, repeated-request caching and an escalation rule.
- How it works
- A job chooses a defined operation over selected evidence. A guard can discard the model’s text and ask the controller for stronger reasoning.
- Verification
- The installed local model completed a synthetic comparison with $0 API cost. In a separate nuanced test, the guard discarded its answer and returned the work for review. No paid escalation ran.
- Limitations
- These were bounded synthetic checks, not a research-quality benchmark. Local computing still uses hardware and electricity; $0 API cost does not mean zero total cost.
- What I learned
- The useful result can be a refusal to overstate what a small model knows.
005 / PERSONAL INTELLIGENCE
PARTIALResearch that keeps its questions open.
- Domain research
- Data collection
- Provenance
30 September 2026
- Problem
- An announcement or a handful of trades can look like a conclusion before it is one.
- My design choice
- Use code to collect repeatable observations, then let AI help review the evidence. Keep missing data next to the conclusion.
- What I built
- Raven / QUEST collection and seller research, an ICP adoption framework, and an IMX token-capture review framework.
- How it works
- Official-source observations and bounded market collection feed evidence records. Missing history and unsupported claims remain explicit.
- Verification
- Production collectors retrieved primary-source texts and market snapshots. Recent collection, checkpoints and partial historical backfill were observed.
- Limitations
- QUEST history is incomplete; Ethereum history is unavailable in the current route. Seller exhaustion, beneficial ownership, adoption outcomes and token value capture are not proven.
- What I learned
- Recording the gap is part of the research, not a reason to hide it.
006 / PERSONAL INTELLIGENCE
TESTEDA private route back to your own machine.
- Local and cloud integration
- Private access
- Recovery testing
30 September 2026
- Problem
- The personal computer should be useful even when the conversation starts elsewhere.
- My design choice
- Keep work on the owner’s computer and connect through an authenticated private route. Check recovery after the connection restarts.
- What I built
- Private HTTPS access, authenticated controller tools, automatic service startup and catch-up.
- How it works
- The system runs on the owner’s computer. A private connection reaches it while the service reconciles saved work and synced memory.
- Verification
- Authentication and private HTTPS checks passed. A connector-only restart returned to the same authorised device while Hermes stayed running.
- Limitations
- Cold-boot and physical-phone acceptance remain pending. The host must be online. The existing OAuth testing configuration needs periodic reauthentication.
- What I learned
- A running process is not proof of connectivity; test the complete return path.
007 / PERSONAL INTELLIGENCE
PARTIALKnow when to ask for attention.
- Event-driven workflows
- Notification design
- Delivery testing
30 September 2026
- Problem
- More observation can easily become more noise.
- My design choice
- Give every job one place to ask for attention. Group duplicates and separate transport acceptance from actual delivery.
- What I built
- A central alert broker with severity, duplicate handling and acknowledgement, plus a Web Push transport.
- How it works
- Jobs can create an in-app alert when attention is required. A permitted device can subscribe to encrypted push.
- Verification
- In-app handling and isolated push encryption, endpoint restrictions, deduplication and acknowledgement checks passed.
- Limitations
- No physical-phone notification receipt is claimed. Device subscription and permission are required; arbitrary custom watch predicates are not complete.
- What I learned
- Delivery acceptance is not the same as a person receiving a useful notification.
008 / PERSONAL INTELLIGENCE
EXPERIMENTALTurn the last run into a better next run.
- Feedback design
- Evaluation
- Human review
30 September 2026
- Problem
- Repeated corrections and failures should become useful feedback.
- My design choice
- Treat reflection as a proposal with evidence, not permission to rewrite the system. A suggested change still needs review.
- What I built
- An experimental reflection process that proposes evidence-linked lessons and improvements.
- How it works
- Bounded reflection reviews events, corrections, source quality and repeated work. Suggestions retain their provenance and authority limits.
- Verification
- The scheduled reflection job completed production runs; governance and source-attribution tests passed.
- Limitations
- Reflection is not unrestricted self-modification. Consequential deployment, expanded permissions and unsupported factual promotion remain outside its authority.
- What I learned
- A proposed improvement needs its own evidence, test and approval path.
009 / PERSONAL INTELLIGENCE
EXPERIMENTALFind the useful part somebody else might need.
- Problem framing
- Capability reuse
- Commercial validation
30 September 2026
- Problem
- A capability built for personal use is not automatically a product with demand.
- My design choice
- Look for a repeatable problem behind proven work. Record what still needs validation before calling it a service.
- What I built
- An experimental Service Opportunity Scout that reviews proven work for possible reuse.
- How it works
- The scout records a possible problem, supporting capability evidence, unknowns and the next validation step.
- Verification
- The scout ran, and a weekly schedule was authorised. Privacy tests prevent sensitive inputs from being relabelled as public opportunities.
- Limitations
- No validated customer demand or revenue is claimed. It cannot contact customers, publish or spend automatically.
- What I learned
- Reuse begins with a real problem and willingness to pay, not a list of features.
010 / PERSONAL INTELLIGENCE
BUILTResearch can return with its sources.
- Integration design
- Evidence contracts
- Data validation
30 September 2026
- Problem
- Outside research must enter memory without becoming unattributed certainty.
- My design choice
- Require incoming research to carry sources and uncertainty. Make duplicate delivery harmless.
- What I built
- A remote-research packet format and bounded ingestion path.
- How it works
- Research arrives with provenance, evidence references and uncertainty labels, then enters the same reviewable record.
- Verification
- Packet validation and duplicate-ingestion tests passed.
- Limitations
- Unattended cloud research while the computer is off needs a separately attached controller. It is not claimed as a continuously running cloud service.
- What I learned
- Portability requires a clear evidence contract, not copying a confident answer.