01ElektraOSmine
My private AI operating system. Started January 2026. Runs locally.
What I am trying to do with it
Keep it as my private internal infrastructure - not a product, not for sale. ElektraOS is the brain that powers my public work: it stores knowledge, runs the agents that audit, draft, and monitor, and gives the other three projects something durable to plug into. The decision I want to lock is to stop expanding it and let it serve the products in front of it.
Statusrunning, port 8000
Repoprivate
What it is
A single FastAPI service that hosts 49 specialised AI agents, each owning a narrow responsibility (content drafting, SEO audit, outreach generation, ledger, monitoring, content backlog drain, agent decline diagnosis). Agents read from and write to a shared markdown knowledge vault, so context persists across sessions instead of being trapped inside individual chats.
What is in it today
- 51 routers, 566 API endpoints, 76 database tables.
- 49 specialised agents.
- Knowledge vault: markdown files with cross-linked MOC (Map of Content) hub pages, an Obsidian-compatible structure.
- Automation bridge: n8n with a workflow library wired to vault events.
- Observability: OpenTelemetry tracing on every request, OpenLIT on LLM calls.
- Hookify guardrails: file-level rules that block accidental writes to .env, em-dash typography, and core vault files.
- Read-only dashboard skill that aggregates server health, agent activity, content backlog, outreach, and revenue into a single view.
Why I built it
Before ElektraOS, my work and knowledge were scattered across Notion, Google Docs, Trello, ChatGPT history, and folders on disk. None of it was queryable. None of it persisted across tools. ElektraOS is the back office that makes everything else I do compound instead of leak.
02elektraos.devmine
My public website and portfolio. The front door.
What I am trying to do with it
Turn it from a personal portfolio into the public face of a Copenhagen-based business this year. The /smb/ and Loomgraph sections already prefigure the product, but the homepage still reads as a freelancer site. The decision I want to lock is whether elektraos.dev becomes the wrapper brand for everything I do, or whether Loomgraph becomes the headline and elektraos.dev shrinks back to a portfolio.
Stack and shape
- Hand-built static site, no framework, deploy on git push.
- DM Sans + Space Mono typography across all pages.
- 10 locale roots: English, Danish, German, French, Italian, Dutch, Swedish, Moroccan Arabic, Ghanaian English, UK English.
- Self-hosted Umami analytics at yossra-analytics.fly.dev/analytics, no Google tracking.
- CSP, X-Frame-Options DENY, GDPR-clean cookie posture.
Personal portfolio side
B2B / Society side
This is the half I am trying to grow into a product. It is a structured set of pages that prefigure what a Copenhagen-based business could look like.
Open question I want your read on: the Loomgraph pages above are not yet wired into a clear CTA from the homepage. I cannot decide whether Loomgraph should become the front-and-centre headline of elektraos.dev, or whether the site stays a portfolio with Loomgraph as a sub-product.
03Loomgraphmine
Agentic SEO and governance for small businesses. Started 20 April 2026. The youngest project but the one with the clearest commercial shape.
What I am trying to do with it
Ship the most defensible commercial product I have built, aimed at Danish and EU small businesses that need AI-readability, multilingual SEO, and a real governance posture but cannot afford an enterprise stack. The bet is that bundling those three into a single membership (with a Society layer where members reinforce each other's authority) is something a one-person company in Copenhagen can credibly run. The decision I want to lock is whether to push it as a SaaS, a Society, or a hybrid.
Two-line pitch
Drop a domain into the registry. Loomgraph onboards it (sitemap, robots, CMS detection), connects it into a shared multilingual Knowledge Graph, and governs it under a signed digital "Pact" with an immutable audit log.
The problem it solves
Small and medium businesses cannot afford the SEO + AI governance stack that big companies are starting to deploy. They cannot prove their site is GDPR-clean, FTC-disclosure-clean, AI-agent-readable, or Schema.org-correct. Loomgraph does this for them, and connects their site into a shared graph with other member sites so they benefit from each other's authority and entity references.
Knowledge Graph
- 53 entities, 39 relations.
- Multilingual aliases on every entity: Arabic, French, Italian, English.
- Schema.org JSON-LD output, sameAs links to Wikidata for canonical identity.
- Content negotiation on /kg/entity/{slug}: HTML for humans, JSON-LD for machines.
- Public sitemap and machine-readable LLM registry.
Governance layer
- 9 policies, 5 regulatory anchors (FTC 16 CFR Part 255, GDPR, Google Search Essentials, plus two more).
- SLAs: 72 hours / 30 days.
- Pact: versioned governance contract, sha256-gated, signable.
- Immutable audit log: append-only, hashed actor IDs, every mutation writes an entry.
- Compliance scanner: regex + parsing for FTC disclosure presence, GDPR cookie banner detection, Search Essentials spam patterns.
- GDPR Article 17: right-to-be-forgotten endpoint that tombstones subject data while preserving a hashed audit trail.
Self-service onboarding
- /public/cohort/apply - rate-limited application endpoint, used by elektraos.dev/smb/.
- /public/join - guest tenant creation.
- /public/pact/sign - guests sign the pact without admin involvement.
- /admin - operator panel for promoting guest sites to permanent members.
Status
- 33 of 33 automated tests passing.
- 4 of my own portfolio domains already registered as tenants.
- Live core loop verified: a registered site signs the pact, the cross-link detector auto-registers entity references, and the KG entity grows reference counts citing real sites.
Where I think this could go: a multi-tenant SMB platform that bundles AI-readability, governance, and cross-site authority into one product. The Society is the social layer where members can see each other and benefit from belonging.
04MealShift Commerce OSwith my uncle
Building it with my uncle Said Ziane in the UK. Not mine to monetise.
What I am trying to do with it
Finish my piece this week (security, agent-native storefronts, activity tracking are already shipped; what is left is closing onboarding gaps for the first paying tenants) so my uncle can start charging UK customers. After that, my time goes back to the three projects above. I am including MealShift here only so you see what is taking my hours this week and why it is not part of my own monetisation question.
What it is
A multi-tenant commerce platform on NestJS (API) + Next.js (storefront), with plugin adapters for WooCommerce, Shopify, and Wix. Runs on Vercel. Stripe Connect, real ledger, refund handling, and FCA-aware safeguarding for marketplace funds.
What we are trying to do with it
Give UK small businesses (restaurants, grocers, florists, pharmacies, general stores) a commerce platform that is open to AI shopping agents from day one. Most existing platforms (Deliveroo, Uber Eats, DoorDash) are login-gated to AI crawlers and shoppers. MealShift is not.
What that means concretely
- Every storefront publishes a sitemap and a robots.txt that explicitly welcomes GPTBot, PerplexityBot, ClaudeBot, and OAI-SearchBot.
- An ACP-style /store/{slug}/feed.json that machine-readable AI shoppers can transact against.
- Schema.org JSON-LD per vertical (Restaurant, GroceryStore, Florist, Pharmacy, Store) on every storefront.
- Platform-wide activity tracking: every API call logs tenant, user, status code, duration, and metadata.
Status
- 4 tenants live in production.
- 0 orders so far, Stripe in demo mode while we onboard.
- Last week I shipped a P0/P1 security batch (Stripe webhook cross-tenant fix, refund stock restoration, login throttle, ledger tenant filter), agent-native storefronts, and platform activity tracking.
- I am pushing this week to close the remaining onboarding gaps so my uncle can start charging.
05How they connect
The four projects share a clear topology. None of them are accidental neighbours.
elektraos.dev (front door, public site)
│
├── chat widget ──────────► ElektraOS (private brain, runs in WSL)
│
├── /smb/#apply ──────────► Loomgraph (governance + KG, on Fly.io)
│
└── /loomgraph/ ──────────► Loomgraph
ElektraOS ◄── HTTP only ──► Loomgraph (no shared code)
MealShift ──── 4 tenants registered as Loomgraph sites
──── plugin layer (Woo / Shopify / Wix) is the
future CMS push-back layer for Loomgraph
What each project gives the others
| From | To | What flows |
| elektraos.dev |
ElektraOS |
chat widget queries route to a 3-tier reply pipeline (FAQ + retrieval + LLM fallback) over HTTPS |
| elektraos.dev |
Loomgraph |
SMB application form posts to /public/cohort/apply, writes a row in Loomgraph's audit log, applicant lands in the registry instantly |
| Loomgraph |
elektraos.dev |
the Society page reads live KG entities and Pact state; /loomgraph/ dashboard shows live sites, edges, pending approvals |
| ElektraOS |
elektraos.dev |
vault content powers FAQ replies; agents draft case study and blog content |
| MealShift |
Loomgraph |
4 of MealShift's tenant domains are already registered Loomgraph sites; storefront sitemaps and feed.json are graph-friendly by construction |
| MealShift plugins |
Loomgraph (planned) |
the Woo / Shopify / Wix adapters become Loomgraph's CMS push-back layer, so audits can result in real CMS edits behind a human-in-the-loop approval queue |
The composite picture: a SMB platform where Loomgraph governs and grows authority, MealShift runs the commerce rails, ElektraOS is the brain that drafts and audits, and elektraos.dev is the public face. Each piece is independently deployable. None of them require the others to keep working.
06Where I am stuck
I have built a lot, the pieces clearly connect, and I cannot tell which is the real product. I keep building bridges between projects instead of choosing one to push hard.
- ElektraOS feels personal and infrastructural. Maybe it stays internal.
- elektraos.dev feels like marketing for something I have not named yet.
- Loomgraph feels like the most defensible commercial idea, but it is the youngest, and right now it is buried inside elektraos.dev instead of being the headline.
- MealShift is my uncle's. My job is to get it shipped this week so it can start being monetised; after that, my time goes back to the three above.
What I am trying to decide: whether elektraos.dev (or one of its sub-products) is enough to turn into a Copenhagen-based business this year, and which monetisation shape (Loomgraph SaaS, agency, hybrid) makes sense.
What I would like from you
Not a pitch. An honest read. Specifically:
- Which of the three would you push if you were in my position, and which would you cut?
- Is Loomgraph (multilingual KG + signed governance pact + SMB SEO) a defensible research direction, a defensible startup direction, both, or just a feature inside a bigger platform?
- Should elektraos.dev be the home of the portfolio with Loomgraph as a sub-product, or should Loomgraph become the headline and elektraos.dev fold underneath it?
- From your consulting work with tech companies, do you see a market shape for any of this in Denmark or the EU, or am I solving a problem that does not have buyers yet?
- What would you tell a former student who is clearly capable but visibly spread too thin?