SelfOS Case Study: Architecting a Three-Layer Behavioral Intelligence Platform
Quick answer: SelfOS is an in-development longitudinal behavioral intelligence platform, an operating system for personal intelligence, built by NeuroStackOS on a strict three-layer architecture separating pure logic, data access, and delivery. It includes a 24-test psychometric engine, five derived profile scores, and a provider-agnostic AI layer built on Cloudflare D1 and Workers. SelfOS is not yet publicly launched, and this case study is presented specifically as an architecture and systems-design deep dive rather than a completed product story, because that is an honest description of where it currently stands.
Why This Case Study Exists Before Launch
Most case studies get written after a product ships, once there are results to report. This one is different on purpose. SelfOS is complex enough, architecturally, that the design decisions behind it are worth documenting on their own merits, independent of launch status, for a very specific audience: senior technical buyers evaluating whether NeuroStackOS can think in systems rather than just ship features. That distinction, systems thinking versus feature shipping, is usually the thing that separates a studio worth trusting with a genuinely complex build from one that is only comfortable with straightforward CRUD apps.
What SelfOS Is
SelfOS tracks how a person thinks, feels, and evolves across a set of defined psychological dimensions over time, functioning as a longitudinal behavioral intelligence layer rather than a single-use assessment tool. Where most personality or psychometric apps give a user one static result and move on, SelfOS is architected around tracking change over time, which is a fundamentally different and harder data and product problem than a one-time quiz.
Achieve Similar Results
Don't leave your engineering outcomes to chance. Book a technical strategy call with our lead architects today.
Book a Technical Strategy Call →The Three-Layer Architecture
The core architectural decision behind SelfOS is a strict separation into three layers, enforced as a rule rather than a loose convention.
| Layer | Location | Responsibility |
|---|---|---|
| Layer 1: Pure Logic | lib/intelligence/, lib/ai/ |
Scoring algorithms, psychometric test logic, and AI orchestration, with zero dependency on how data is stored or delivered |
| Layer 2: Data Access | lib/data/ |
All database interaction, isolating storage details from the logic layer above it |
| Layer 3: Delivery | worker/src/, app/api/, components/ |
API endpoints, routing, and UI components, the only layer allowed to depend on the specific delivery mechanism |
This separation matters more than it might sound like on first read. A platform that mixes scoring logic directly into API route handlers, for instance, becomes extremely difficult to change later, because a change to how a test is scored risks breaking the API contract, and a change to the API risks breaking the scoring. Enforcing strict layering means the psychometric logic can be tested, audited, and modified independently of the delivery layer, which is exactly the kind of discipline that becomes essential once a platform reaches SelfOS's level of complexity: 24 tests, 5 derived scores, and an AI layer, all needing to interact correctly.
The Technical Stack
| Component | Technology |
|---|---|
| Frontend framework | Next.js 13.5 App Router with React 18 |
| Styling and components | Tailwind CSS with shadcn/ui |
| Animation | Framer Motion |
| Data visualization | Recharts |
| Authentication | Clerk |
| Database | Cloudflare D1, an 11-table schema |
| API layer | Cloudflare Workers with JWT authentication, 13 endpoints |
| AI provider | Groq, running llama-3.1-8b-instant |
| Hosting | Cloudflare Pages |
A Provider-Agnostic AI Layer, By Design
One of the more deliberate architectural choices in SelfOS is that the AI provider is never hard-coded into application logic. A dedicated AI abstraction, lib/ai/aiClient.ts, reads its provider, endpoint, API key, and model entirely from environment variables (AI_PROVIDER, AI_API_ENDPOINT, AI_API_KEY, AI_MODEL). This means switching from Groq to a different AI provider entirely is a configuration change, not a code change. For a platform whose core "Ask SelfOS AI" feature depends on querying a user's own longitudinal data through an LLM, that flexibility is not a nice-to-have. AI provider pricing, performance, and availability all shift over time, and a platform locked to one provider's SDK at the code level inherits all of that provider's risk directly. SelfOS was built to avoid that from day one.
The Psychometric Engine
SelfOS runs 24 psychometric tests through a JSON-defined test engine, meaning new tests can be added as structured data rather than requiring new application code for each one. Results feed into five derived profile scores: analytical, creativity, purpose, awareness, and motivation. Additional features built on top of this core include a Personal Timeline tracking change over time, three distinct streak types for engagement, an Anonymous Community Wall organized around eight tags, and an Ikigai Finder feature, which is fully wired and functional.
Being Honest About What Is Not Finished
A case study that only lists finished features is not trustworthy, and SelfOS has real, specific work still in progress that is worth naming directly rather than glossing over.
- Phase 2 is currently blocked by a schema discrepancy between the approved 11-table D1 schema and a 4-table Phase 2 summary, currently under investigation. This is a real, unresolved engineering question, not a solved problem being described in hindsight.
- The Dopamine Detox Game has a completed UI, but its backend is not yet wired.
- Dream Decoder and Reality Check exist as features but are currently feature-flagged off.
- WhoAmI, a planned Personality Mirror feature, has not been built yet.
- All feature flags in
lib/config/features.tsare currently set to false. - SelfOS is not yet publicly deployed.
Naming an active, unresolved blocker in a public case study is an unusual choice for a marketing page, and it is the right one anyway. A platform this architecturally ambitious will have open questions at any given snapshot in time, and pretending otherwise would undercut the actual point of this case study, which is demonstrating real systems-level thinking, not a polished highlight reel.
Why This Matters for Senior Technical Buyers
If you are evaluating a development partner for something more architecturally demanding than a marketing site or a simple CRUD app, SelfOS is the proof that NeuroStackOS thinks in layers, data contracts, and provider independence before writing feature code, not after a rewrite becomes necessary. That is a different, harder skill than fast execution, and it is the skill this specific case study exists to demonstrate.
Frequently Asked Questions
What is SelfOS?
SelfOS is an in-development longitudinal behavioral intelligence platform, an operating system for personal intelligence, built to track how a person thinks, feels, and evolves across defined psychological dimensions over time, rather than delivering a single static result.
What is the three-layer architecture, and why was it chosen?
SelfOS separates Pure Logic, Data Access, and Delivery into three strictly enforced layers, so that scoring algorithms and AI orchestration have no dependency on storage or delivery details, which keeps a platform this complex changeable without breaking unrelated parts of the system.
How many psychometric tests does SelfOS include?
SelfOS runs 24 psychometric tests through a JSON-defined test engine, producing five derived profile scores covering analytical thinking, creativity, purpose, awareness, and motivation.
Is SelfOS publicly available yet?
No. SelfOS is not yet publicly deployed. This case study documents its architecture and engineering decisions as an active, in-development build, including a currently unresolved schema discrepancy blocking Phase 2.
How does SelfOS use AI without being locked into one provider?
Through a dedicated AI abstraction layer that reads the provider, endpoint, API key, and model entirely from environment variables, meaning a provider switch is a configuration change rather than a code rewrite.
Related Case Studies
- Billr: another in-progress build documented transparently rather than held back until launch
- MailBurn: a comparably complex infrastructure build, for a systems-architecture comparison
- Capitalyst and Second Encounter: additional products currently in active development at NeuroStackOS
Work With NeuroStackOS
If your project needs architecture that will still make sense after six months of feature additions, not just a fast first version, this is the level of systems thinking NeuroStackOS applies from the first design decision. Get in touch to talk through a complex build.