001 · P0 · KNOWLEDGE FOUNDATION · SOURCE-VERIFIED · IN THE FIELD
AI Evolution Observatory
A temporal, provenance-aware knowledge system for reconstructing and explaining the evolution of AI. At P0 — knowledge foundation only: epistemic, temporal and governance models settled before any application stack is called canonical.
- QUESTION
- How do you say what was true about artificial intelligence at a given moment — and show what that claim rests on?
- CONTRIBUTION
- Simon settled the epistemic, temporal and governance models before anything else: what may be asserted, how time is represented, what counts as evidence, and who is allowed to promote something to canonical.
- TODAY
- A written constitution and an explicit scope boundary.
- Normative epistemic and provenance models, with conformance cases to test them against.
- A standing rule that generated output is never itself authoritative evidence.
- NOT YET
- No application stack, database, framework or ingestion pipeline is canonical.
- No graph, no timeline, no analysis and no reader-facing projection exists.
- CONSTRAINT
- Canon, knowledge graph, analysis, scenario and experience stay rigorously separated. A simulated or counterfactual state must never become readable as a claim about what actually happened.
- STILL OPEN
- Which sources can sustain a time-aware, auditable record at any real scale.
- What the first application layer should be, and when it earns the right to exist.
- SOURCE
- Source not public.
002 · GRAND REBOOT · R0.1 · SOURCE-VERIFIED · OUTSIDE THE FIELD
Food OS
In its Grand Reboot, at increment R0.1 — problem and truth discovery. First problem, first wedge and first product are held UNKNOWN; stack and architecture unselected; implementation not authorised. The systemic food-chain ambition is real but does not define current scope, and AI is not a validated requirement.
- QUESTION
- Which food problem actually deserves to be solved — before anyone decides how to solve it?
- CONTRIBUTION
- Simon restarted the project as a discovery exercise and made the repository a record of reasoning: problems observed, hypotheses tested, evidence gathered, decisions made and assumptions rejected.
- TODAY
- A written set of principles and a discovery increment in progress.
- An explicit rule that the existence of the repository does not authorise implementation.
- NOT YET
- First problem, first wedge and first product are all held at unknown.
- Stack, architecture and data model are unselected. Implementation is not authorised.
- AI is not a validated requirement for anything here.
- CONSTRAINT
- A systemic ambition is never sufficient justification for a feature, a data collection or an architecture. Impact does not imply ownership.
- STILL OPEN
- Which recurring problem shows up in observable behaviour rather than in stated enthusiasm.
- SOURCE
- Source not public.
003 · FOUNDATION PHASE · SOURCE-VERIFIED · IN THE FIELD
Moka Companion
A native Windows desktop companion: presence, attention, lightweight native interaction, privacy, subtle assistance. Its normative v0.1 contract forbids cloud service, LLM, AI inference and runtime networking — requirements, not demonstrated runtime behaviour. One relation, held deliberately.
- QUESTION
- How small can a desktop presence be and still be worth having — with no cloud, no model and no network?
- CONTRIBUTION
- Simon wrote the contracts before the code: the sprite asset and its provenance, the runtime design, a privacy boundary written to be mechanically checkable, and a resource budget with hard gates and a measurement protocol.
- TODAY
- Normative contracts for the asset, the architecture, privacy, provenance and the resource budget.
- The sprite asset itself, with its origin and integrity recorded.
- NOT YET
- Implementation has not begun. There is no source, no build and no running program.
- Distribution rights for the asset are unresolved.
- CONSTRAINT
- The v0.1 contract forbids cloud service, model inference and runtime networking, and forbids observing what you type in other applications. When there is nothing to do, the program does no work: no render loop, no polling, no repeating timer.
- STILL OPEN
- Whether the resource budget survives contact with a real implementation.
- SPECIFIED WITH
- Rust · Win32 · Windows 11 x64
- SOURCE
- Source not public.
005 · PHASE UNDECLARED · SOURCE-VERIFIED · IN THE FIELD
HERVÉ
An offline-first operational platform documented and implemented around operator workflows, cycle counting, stock and replenishment, and operational dashboards. Its founding doctrine positions it as a bridge between central information systems and operational work. Deployment, scale and operational results are not claimed.
- QUESTION
- Can a lightweight operational system become the missing layer between enterprise software and physical reality — without forcing operators to work for the software?
- CONTRIBUTION
- Simon designed and built HERVÉ as an offline-first operational platform for the point where central information systems stop and physical work begins. It captures field reality, embeds operational rules into workflows and turns everyday activity into traceable data for operators and managers. The architecture is designed to complement an ERP, WMS or CMMS where one already exists, while remaining capable of operating tactically on its own within the domains it covers.
- TODAY
- A working offline-first operational platform with implemented workflows spanning stock, cycle counting, replenishment, preparations and operational control.
- A local synchronization model with queued actions, replay, server-side idempotence and explicit handling of degraded network conditions.
- Operational and managerial surfaces built from the same underlying activity, including read-only multi-site views.
- Business rules, lifecycle guards, auditability and executable contracts around selected critical workflows, with CI used to protect selected semantics from regression.
- Bounded statistical forecasting paths exist inside the operational-intelligence layer; validated predictive performance is not claimed.
- NOT YET
- No claim of enterprise-wide deployment, cross-industry replication or measured business impact.
- Validated predictive performance, broad prescriptive automation and an operational digital twin are not claimed.
- The platform is not presented as a generic drop-in replacement for an ERP, WMS or CMMS.
- CONSTRAINT
- Complexity belongs in the system, not with the operator. Offline operation, explicit state transitions, traceability and the distinction between system truth and field truth are treated as correctness constraints rather than optional features.
- STILL OPEN
- How far the architecture transfers beyond its originating operational context without losing the simplicity that makes it useful.
- Which combination of modules forms the smallest credible standalone operational system.
- BUILT WITH
- PHP · SQLite · Vanilla JavaScript · PWA / Service Worker
- SOURCE
- Source not public.
006 · PHASE UNDECLARED · SOURCE-VERIFIED · IN THE FIELD
EXOMIND
A research program for embodied AI: cognition, planning and skill arbitration above a robot's real-time control boundary. Its founding work defines the architecture, experiment gates and an evidence register before autonomy; generative output and remote agents are not permitted to drive the motors directly. Nothing has yet been operated, trained, measured or replicated.
- QUESTION
- What does it actually take to put a reasoning system into a body — and how much of that can be established before touching the hardware?
- CONTRIBUTION
- Simon produced a versioned founding technical atlas: a reconstruction of the platform and its sources, an embodied-AI architecture, staged experiment gates, a structured research programme, a skills-depth map, an evidence register and a register of open questions.
- TODAY
- A versioned founding technical corpus with a checksum manifest, pinned code revisions where reproducible and dated consultation of mutable sources.
- An architecture decision: the real-time control layer remains the only writer to the motors, and EXOMIND sits above it as cognition, planning and skill arbitration.
- A structural prohibition — no generative model output, no remote agent and no experiment script may drive the motors directly.
- A structured programme of thirty planned physical experiments, alongside explicit evidence and unknown registers. Designed experiments are not reported as results.
- NOT YET
- Nothing has been operated, trained, measured or replicated. A manufacturer or maintainer measurement is not treated as an EXOMIND replication.
- No original robot, no custom electronics and no modification to the first body.
- CONSTRAINT
- The first body is treated as an instrument, not a project: freeze the baseline before changing anything, build observability before autonomy, and no drilling, no parallel power supply and no actuator replacement until that baseline is complete.
- STILL OPEN
- The gap between simulation and reality, which is precisely what the experiment programme exists to measure.
- Which capabilities transfer from a documented body to an original one.
- RESEARCHED WITH
- MicroDuck (Pollen Robotics) — third-party robot platform · MuJoCo simulation · Reinforcement learning, ONNX policy export · Python
- SOURCE
- Source not public.
OUTSIDE THE FIELD
World Press Lens
An observatory of global media framing: which topics dominate the world press, how the same story is framed across countries and languages, and which important stories a national press is barely covering.
- QUESTION
- Can you make media framing visible — and stay honest about how weak the evidence behind such a comparison really is?
- CONTRIBUTION
- Simon built the pipeline end to end and documented its limits as carefully as its features: fictional seed data labelled fictional, heuristics labelled heuristics, editorial labels labelled unverified, and legal review named as a precondition for production rather than a formality.
- TODAY
- A working pipeline: ingest, deduplicate, cluster into topics, score, compute blind spots, serve read APIs.
- A mobile client with signals, topic detail, search, blind spots, statistics and settings.
- A backend test suite covering deduplication, clustering, scoring, blind spots, search, statistics and seeding.
- NOT YET
- It runs on fictional seed data. A live provider exists but is experimental, and both its field semantics and its terms of use are unverified.
- No licence decision, no continuous integration, no authentication, no rate limiting.
- Not legally cleared: press and database rights, attribution and takedown processes are unreviewed.
- CONSTRAINT
- The clustering is lexical and the scores are heuristics. This must not be described as authoritative, globally representative or production-ready — and its own documentation says so before anyone else can.
- STILL OPEN
- Whether lexical clustering survives real multilingual volume.
- What licensing actually permits at the metadata level, jurisdiction by jurisdiction.
- BUILT WITH
- Python · FastAPI · PostgreSQL · React Native / Expo client · pytest
- SOURCE
- Source not public.
OUTSIDE THE FIELD
FactoryPulse
A playable simulation of a small factory, built to teach how an industrial system actually behaves under decisions. Drawn from CPIM, Lean and the Theory of Constraints.
- QUESTION
- Why does improving one part of a production system so reliably make the whole system worse?
- CONTRIBUTION
- Simon built the simulation, the decision set and the explanation layer. Every action states what it improves, what it degrades, which concept it illustrates and what to watch afterwards.
- TODAY
- A running hourly simulation of material, cutting, assembly, quality control, finished stock and customer, with buffers, work in progress, wear, breakdowns, defects and variable demand.
- Around twenty decisions with real effects, and a bottleneck that moves when you lift it.
- Operational indicators — service level, throughput, work in progress, lead time, equipment effectiveness, defect rate — plus hidden system variables surfaced through a diagnostic.
- Five scenarios and a structured debrief. No installation, no dependencies, no server, and nothing leaves the machine.
- NOT YET
- The economic model is simplified and balanced by hand, not calibrated against a real plant.
- Flow is modelled in quantities rather than individually traced units.
- No advanced planning, no multi-product routing, no explicit changeovers.
- CONSTRAINT
- It has to stay simple to understand and hard to master. Every decision improves one indicator and usually degrades another — that tension is the teaching, not a defect to be balanced away.
- STILL OPEN
- Whether the balance holds up against people who play it seriously rather than politely.
- BUILT WITH
- HTML · CSS · JavaScript · Runs offline in a browser
- SOURCE
- Source not public.
OUTSIDE THE FIELD
ProjectTrail
A local-first, content-blind temporal memory for people working across several projects at once. The time is already there; you decide what it meant.
- QUESTION
- Can a tool remember when you worked without ever inspecting what you were working on?
- CONTRIBUTION
- Simon wrote the product constitution first, including an explicit anti-product document: the scope exclusions and anti-drift rules that stop it becoming a productivity judge, a task manager or a monitoring system.
- TODAY
- A frozen product constitution with normative invariants and change-control boundaries.
- A product thesis with a stated falsification target, a privacy model and an explicit anti-product scope.
- NOT YET
- No product runtime exists. Nothing captures, stores or displays anything yet.
- CONSTRAINT
- Zero passive capture of work content. Automation is not truth, observation is not interpretation, and the user keeps real deletion authority over their own record.
- STILL OPEN
- Whether retrospective attribution stays cheap enough that a person actually does it.
- SPECIFIED WITH
- Windows first · Local-first — no account, no backend
- SOURCE
- Source not public.
OUTSIDE THE FIELD
Personal Site
This site. A static instrument for representing a practice, built so that a stranger can inspect the engineering instead of taking the claims on trust.
- QUESTION
- Can a personal site be held to the same evidence standard as the systems it describes?
- CONTRIBUTION
- Simon built the site and its integrity machinery around a deliberate separation of identity, evidence and presentation. Provenance records attach to system identities independently of where those systems are shown; every plotted FIELD system must have one, while displaying an entry in WORK or LAB does not itself create that requirement. Build checks enforce the declared structure without pretending to verify every sentence on the site.
- TODAY
- A static site that ships zero client-side JavaScript.
- Build-time validators: a system marked source-verified with no qualified source behind it fails the build, and relations, placements and identifiers are all checked before anything renders.
- A content-hash manifest over the resources registered with the Observer — the field, the front index and each plotted system — which detects when one of them changes. It is not a hash of every published page.
- A live production deployment at sstm117.com, with its canonical origin, social metadata, a sitemap and Cloudflare Workers Static Assets hosting.
- NOT YET
- No measurement of post-launch maintenance effort is documented in this repository.
- CONSTRAINT
- No client-side JavaScript. Interaction has to be expressible in links and CSS, or it does not ship.
- STILL OPEN
- Whether a site this restrained reads as rigorous or as reticent. That is a question about readers, and it has not been tested.
- BUILT WITH
- Astro · TypeScript