WORK — sstm117

INDEX

AI Evolution ObservatoryFIELD
Food OSFIELD
Moka CompanionFIELD
Foundry NodeFIELD
World Press Lens
FactoryPulse
EXOMIND
ProjectTrail
Personal Site

001P0 · KNOWLEDGE FOUNDATIONSOURCE-VERIFIEDIN 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. Its vision reaches into physical AI infrastructure, which is why physical systems is a declared concern.

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.

002GRAND REBOOT · R0.1SOURCE-VERIFIEDIN 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.

003FOUNDATION PHASESOURCE-VERIFIEDIN 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.

004PHASE UNDECLAREDOWNER-DECLAREDIN THE FIELD

Foundry Node

Heterogeneous physical computing nodes and their role in distributed software systems. Constrained hardware, hardware reuse, experimentation. Operations is secondary: constrained nodes imply lifecycle and availability without making this an operations project. No lifecycle state is declared.

QUESTION: What can heterogeneous, constrained and reused hardware actually do inside a distributed software system?
CONTRIBUTION: Simon declared the research direction and its boundary: constrained nodes imply lifecycle and availability concerns without turning this into an operations project.
TODAY: A declared research direction. The repository is a single paragraph, and that is the honest extent of it.
NOT YET: No node is characterised, no capability is demonstrated and no lifecycle state is declared.
CONSTRAINT: Capability has to be verified before a role is chosen. The first useful step is small, reversible and discriminating rather than ambitious.
STILL OPEN: Networking, storage, headless operation and useful workload are all open questions.
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

EXOMIND

A research program for embodied AI: a cognition and planning layer above a robot’s real-time control boundary, using one thoroughly documented body to learn the whole discipline — source, model, build, control, measurement, learning, deployment and recovery.

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 the founding technical atlas: a reconstruction of the platform pinned to specific published revisions, an architecture decision, a staged gate structure, a structured experiment program, a skills-depth map, an evidence register and a register of open questions.
TODAY: A thirteen-document founding corpus, with every moving source pinned to a revision and a consultation date.
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.
Twenty recorded facts, twenty recorded unknowns and twenty designed experiments, each labelled by how strongly it is actually supported.
NOT YET: Nothing has been operated, trained, measured or replicated. The atlas states plainly that a manufacturer’s measurement is not a 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 program 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: Not published.

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, and drew the line where that machinery stops: each system plotted in the field carries a source record and is checked at build time, while the standalone entries, the fragments and the notes carry no such record and are held to the same standard editorially.
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
SOURCE: github.com/sstm117/sstm117-site