In 2016 I was working as Community Manager at Devcenter.co, a Nigerian community of developers, designers, and other technical people, based in Lagos. The community had originally formed around building open-source software together — public, freely available code projects that anyone could contribute to. Part of what Devcenter did, alongside running the community itself, was run a matching business. Companies would come to us needing technical work done — a website, an app, a piece of software infrastructure — and we would connect them with developers, designers, and other technical talent from within the community. We managed the project. We sat in the middle, as the intermediary between the client with money and the community with skill. That was how the business made money.

The constant problem was supply. We never had enough people in the community who were skilled enough to deliver client work well. Clients would come to us, and often we'd struggle to find someone ready to take on the job properly, and either we'd lose the client or the delivered work would fall short of what the opportunity deserved. This wasn't a small friction sitting at the edge of the business. It was the actual ceiling on how big the business could get. We weren't limited by how many clients wanted work done. We were limited by how many people in our community could actually do the work.

While living inside that problem, I started noticing something odd. People who had been asking basic, beginner-level questions in the community a few months earlier were now the ones fielding hard questions from other people. This wasn't one standout person. It kept happening, across different individuals, at a pace that didn't match anything I understood about how skill development normally worked. Nobody had built a training programme for this. Nobody had assigned mentors or designed a curriculum. It was happening on its own, inside the community, with no one deliberately steering it.

That observation turned into the actual question that everything else in this account grew out of. If this kind of accelerated skill growth was happening organically, with no one engineering it on purpose — what if the underlying mechanism could be found, understood well enough to be taken apart, and then deliberately switched on? Not admired from a distance, not just relied on as a stroke of luck for the people it happened to — actually engineered, so it could be made to happen faster, and for more people, on purpose.

If that were possible, the matching business wouldn't be limited by whatever supply of skilled people happened to show up in the community naturally. We could manufacture the supply directly. Take an ordinary group of people — no special starting advantage, no existing technical skill — and deliberately produce skilled talent out of them, and then do exactly what the business was already doing with that talent: place them on real client work, manage the projects, take a share of the value created. I thought about this in terms of how China had built enormous wealth through its manufacturing and construction industries — training up a large working population and then putting that trained population's output to use at scale, repeatedly, across the economy. I wanted to do the equivalent for the emerging tech and digital-infrastructure economy, with skilled people instead of steel and concrete as the output being manufactured.

So I went looking for the actual mechanism sitting underneath the pattern I'd noticed. What was really happening when someone moved from asking beginner questions to answering hard ones, in a matter of months, with no one managing the process on their behalf?

What I found was this. People were contributing to real open-source projects — actual working software that other people depended on, not practice exercises built for the sake of learning. When they hit something they didn't understand, they'd ask about it in the community, and someone else working on the same project would answer. They'd apply the answer, often get it wrong or only half-right the first time, get more feedback on what was off, fix it, and move on to the next piece of the problem. Task, feedback, improvement, more task. Around and around, continuously.

It wasn't a course, with a fixed syllabus moving people through content in a set order. It was closer to an oven. You put something in, heat gets applied continuously and evenly, and what comes out has actually changed — baked, structurally different from what went in, not just decorated on the surface. The loop itself was the mechanism doing the work. Not any single lesson sitting inside it.

And the loop worked fast specifically because it was tight. The community answered questions quickly — often within hours, sometimes within minutes. The feedback came back to a person before they'd mentally moved on to something else entirely, while the mistake they'd made was still fresh enough in their mind for the correction to actually mean something and reshape how they thought about the problem. If the same person had been working through the same material alone, or inside a slower-responding environment, the loop would have stretched out, and the rate of learning would have stretched out along with it. The speed at which feedback returned to a person was doing as much of the actual work as the content of the feedback itself.

There was a second element underneath the first one, and it took me longer to notice it clearly. People weren't contributing to these open-source projects because anyone had told them to. They were contributing because the projects were genuinely good — real work that carried social weight inside the community, the kind of project you wanted your name visibly attached to. Contributing to it was a way of being seen doing something worthwhile. It wasn't homework being completed under obligation. The learning that resulted was a side effect of people chasing something they actually, independently wanted — a completely different engine from a training programme that has to work at motivating people to sit through material they've been assigned.

Once I could see this mechanism clearly enough to name its parts — a tight, real-stakes feedback loop, running on genuine social motivation rather than assigned obligation — I started noticing versions of the same pattern everywhere I looked, not only inside Devcenter's own community.

The first attempt to deliberately build a system around this observation was called Learn by Doing. It combined three things at once: project-based learning, meaning people worked on real projects rather than practice exercises; task-based learning, meaning those real projects were broken down into smaller, manageable individual tasks rather than handed over whole; and an apprenticeship structure, meaning experienced mentors worked one-on-one with learners in private spaces, available to answer questions directly. Each task came with a short, bite-sized explainer attached to it, meant to lower the barrier to actually starting.

This attempt failed, and it's worth stating that plainly rather than skating past it. Learners started with real enthusiasm. After roughly two weeks, participation consistently dropped off. Trying to fix this by offering incentives for continued contribution did not solve the problem. This is the honest starting point for everything that followed: the first deliberately engineered version of this idea, tested for real with real people, did not work as it was originally built.

Failed early — real drop-off, incentives didn’t fix it

Rather than making small adjustments to the same format and hoping for a different result, this failure prompted a direct, specific question: why don't the learning environments that actually achieve strong completion have this same drop-off problem? That question sent me looking for successful examples elsewhere, and researching what they were actually doing differently.

Two external reference points anchored the next attempt at a system.

The first was the altMBA, an online leadership and management programme founded in 2015 by Seth Godin, run through his company Akimbo. It reported a completion rate of 96%, against a documented industry average of just 4% for online courses generally — roughly a 24-times difference in a metric that most online education simply treats as an unavoidable cost of the format, something you accept rather than something you try to fix. The altMBA ran intense four-week cohorts, engaging more than 100 students at a time using ordinary digital tools — Slack for messaging, WordPress for content, Zoom for video sessions. In one documented 2016 cohort, students came from 27 different countries and 85 different industries.

What mattered most wasn't the completion number itself, but the explanation Akimbo's CEO, Marie Schacht, gave for why it happened. She described it this way: "People add the learning time to their calendars and for them, it is time with other people, not just time to learn." Completion, in other words, wasn't being solved through better course content. It was being solved by turning what would otherwise be solitary study into a social commitment people didn't want to miss. Schacht also noted that members who had completed the programme four years earlier were still in regular contact with people from their original first-week cohort group — the community the course created had outlasted the course itself.

The second reference point was Josh Kaufman's 2013 TEDx talk, given at Colorado State University, on learning any new skill in roughly 20 hours. He broke the process into four sequential steps: deconstruct the skill into its smallest component parts; learn just enough about each part to be able to self-correct as you go; remove the practical barriers standing between you and actually practising; and then practise, deliberately and consistently, for at least 20 hours.

These two reference points — one about sustaining engagement through social commitment, one about compressing the mechanics of skill acquisition into a repeatable process — were combined into a new venture called Frintern, short for Freelance Interns. Frintern was later continued under a different name, techstarta.com, by a co-founder after my own departure from the company.

Kaufman's four steps were used as a direct structural mould for Frintern, with a specific, concrete mechanism built against each one:

Deconstruct the skill. Various professional work skills were broken down using first-principles reasoning — starting from the most basic underlying elements of a skill and rebuilding understanding upward from there, rather than working from convention or analogy to something else. This process was supplemented with direct interviews with genuinely skilled practitioners in each field, asking them to walk through how they actually approached problems in their domain. The output of this deconstruction process was a set of mental models for each skill — compressed, directly actionable representations of how an experienced practitioner actually thinks through a problem in that specific domain, rather than a general description of the field.

Learn enough to self-correct. Existing free learning resources, already available online, were curated and restructured into small, bite-sized pieces, hosted on a purpose-built microlearning system — a system designed around the same principle used by language-learning apps like Duolingo, where material is broken into short, frequent, low-effort sessions rather than long single sittings.

Remove barriers to practice. A personalisation system was built to match individuals to skill paths suited to their existing natural affinities. The underlying reasoning: someone who grew up swimming in a river has a genuine head start toward becoming a competitive swimmer compared to someone who's never been near open water, and a single generic curriculum that ignores this kind of existing affinity is discarding a real, usable advantage.

Practise for at least 20 hours. Structured "Learning Labs" and time-boxed sprints put learners directly onto real-world projects to apply whatever new skill they were developing, rather than working through isolated practice exercises disconnected from anything real.

Each of these four interventions was treated, at the time, as independently reducing what was called Time-to-Learn-Skills, or TTLS — how long it takes someone to go from first encountering a skill to being able to apply it reliably on their own. This was expressed, somewhat informally at the time, as a simple formula: the new TTLS equals the old TTLS minus the combined time saved by each of the four interventions above. The formula's specific mathematical precision was never really the point. The point was that TTLS was being treated as a variable that deliberate, structured intervention could actually move — not a fixed cost that simply had to be accepted, the way most learning approaches implicitly treat it.

This produced a genuine, dated, measured result. In pilot workshops run between March and May 2018, participants using this combined Frintern system were able to learn a new skill and use it to actually create something functional in 2 to 3 hours — a substantial reduction from Kaufman's already-compressed 20-hour baseline. This remains the only hard, dated figure for TTLS reduction anywhere in this whole body of work. It came from a specific set of pilot workshops over a specific three-month window, and it has never been reproduced or re-measured at a larger scale since.

Tested twice — one hard, dated result, never reproduced at scale

After explaining the resulting system to Sean Burrowes — at the time Chief Operating Officer at Ingressive, later Director of Business Development at Semicolon — he described what I'd built as "The Innovation Engine." The system was subsequently given its own formal name: the Growth and Innovation System, or GIS.

Frintern also made a genuine attempt at technical automation of the whole system, not just delivering it through manually run workshops. Before my own departure from the company, three components were built and demonstrated working together in a connected way: a digitised version of the learning process, usable across text, audio, or video; a working (if basic) personalisation engine matching individuals to skill paths based on affinity; and a microlearning management system supporting self-directed learning of work-based mental models. What was honestly identified as still missing at this stage — clearly and specifically, not glossed over — was any working mechanism for genuinely many-to-many interaction happening in a virtual space. Physical communities like the one at Devcenter naturally supported many people learning from many other people simultaneously. No equivalent existed yet online.

The Growth and Innovation System's structure — later formalised into three components, described in the next chapter — was tested through actual paid training delivery to real clients, not only refined internally.

The African Fintech Foundry, referred to throughout this account as AFF, is a Nigerian fintech accelerator programme — an organisation that supports early-stage financial-technology startups by running structured cohort programmes for them. After helping organise AFF's first demo day (a public event where startups present their progress to investors and partners), I was invited to deliver training to the first cohort of AFF's Fintech Accelerator Programme.

This training centred on five named thinking frameworks — Design, Business, User, Market, and Project — the same five domains that remained the backbone of every version of this system that followed. A framework, in this sense, is a structured set of questions someone experienced in a given domain automatically asks when they encounter a new problem — made explicit enough that someone less experienced can borrow that pattern of thinking before they've earned it themselves through years of practice. One concrete outcome from this specific AFF cohort is worth recording directly: partway through the programme, participants realised they had been building a product first and searching for a market to fit it into afterward, and that this needed reversing — understand the market and what it actually needs first, and let that understanding shape what gets built, rather than the other way around. The frameworks weren't abstract theory to that cohort. They visibly and directly changed how a group of real founders approached a real, live strategic decision.

This engagement led directly to a second, independent paid engagement, initiated by Hugo Obi, founder of Maliyo Games (a Nigerian game-development company), ahead of his team's launch of a new fintech product. There was real reluctance and pricing friction on both sides at the outset — this wasn't an easy or obvious sale. Maliyo's team gave direct feedback afterward that helped refine the training material further, and the engagement itself served as a genuine second test of whether the frameworks generalised beyond the specific startup context they'd originally been built and tested for at AFF.

The substance inside each of the five frameworks — what each one is actually built to notice — came from years of direct, situated observation of real Lagos communities and markets, not from imported management theory applied from a distance.

The User Framework — built around the question of what a person is actually trying to accomplish, beneath their stated goal — is grounded directly in something I call the Five-Star Dilemma. Three different people, asked separately about how they used star-rating systems like Uber or Google Maps, gave three genuinely different, internally coherent personal philosophies, none of which they'd have volunteered if simply asked in the abstract to describe their "approach" to rating things.

One person refused to give a low rating to a driver who had been rude and driven recklessly throughout a trip. Her explanation: "I can't give him a low rating na; that's where he eats. I'm not a bad person!" — prioritising the driver's livelihood over an accurate reflection of the experience, out of a "we are our brother's keeper" ethic.

A second person, after finishing a genuinely good meal at a restaurant, gave three stars rather than five. Asked why, he explained with complete seriousness: "I give three stars to a good place where they did what they said they'd do and the experience was satisfactory. Four stars are for places that go above and beyond... Then five stars is for God; only God is perfect." A cultural and religious framing in which perfection is reserved for the divine, and genuine satisfaction is rightly represented well below the top of the scale.

A third person simply didn't bother engaging with rating systems at all unless something was exceptional or notably bad, on the pragmatic reasoning that only the extremes deserve the effort of a rating.

Three real, coherent decision policies, each one internally consistent, each one completely invisible if you'd simply asked "what's your approach to ratings?" as an abstract question. Discoverable only by watching what each person actually did, case by case. This single observation is the load-bearing insight underneath everything else in this account: behaviour is more honest and more reliable than self-report, and real judgement lives in the pattern of what someone actually does, not in the explanation they give for it afterward.

The Business and Market Frameworks draw directly on TKD Farms Farmers' Market, a weekly market held in Ikoyi, Lagos. A vendor there named S, founder of an organic skincare and haircare brand called Infused Organics, described how a single customer suggestion — for a citrus-infused product — led directly, through her own action on it, to a new collaboration with a neighbouring vendor who sold dried fruit, and from that collaboration, a genuinely new best-selling product. Value being created directly through fast, direct customer signal, not through formal market research.

The User and Business Frameworks together draw on El Padrino, a Lagos taco restaurant. Rather than competing primarily on food quality, El Padrino built its following by treating returning customers personally, like friends, and by running social events — parties, bingo nights, bar crawls — that had little directly to do with food. The restaurant stayed anchored to this one community rather than trying to broaden its appeal. When El Padrino changed physical locations multiple times, its loyal customer base followed it each time, and it became known locally as "the Maggi of Tacos" — Maggi being a dominant, near-synonymous-with-the-category seasoning brand in Nigeria, so the comparison meant El Padrino had become the default, category-defining name in its space.

The Market Framework's question about identifying unserved segments draws on Jay's Diner, a Lagos establishment that built a loyal following by operating exclusively between 6pm and 5am, treating the night-shift and insomniac crowd as its actual primary audience rather than an afterthought tacked onto ordinary daytime hours.

The Design and User Frameworks together draw on The BodyLanguage Company, a Lagos dance studio that ran near-daily free dance classes at bars and lounges across the city. People who came simply to enjoy a night out and dance would naturally want to improve, and would turn to the same instructors who had introduced them to it, converting free, casual attendance into paid lessons — without the studio ever needing to sell anything directly.

By 2019, the full system — by now combining the community-side observations described in Chapter Seven with the Frintern-side learning mechanics described in Chapter Five — was written up in full and published as an open-access book titled Building Communities into Economies. It was released under an open licence via GitHub, explicitly intended to be forked, remixed, and translated freely by anyone who wanted to build on it. Its second half speculated forward toward an AI-augmented future version of the system, and did so with consistent, deliberate hedging throughout, rather than describing anything as already built — phrases like "is being developed to" and "this is not a near-term outcome, it is a direction" appear repeatedly in that section, marking it clearly as speculative rather than demonstrated.

Around this same period, the underlying structure of the system was captured in a diagram — the rawest, most complete visual description of the whole thing that ever existed. It's worth describing this diagram in full, in words, since it's the single clearest artefact showing what the system actually was, in its original, uncompressed form, before anything got simplified away.

At the centre-left of the diagram sits a circle labelled "The Problem." Three things feed into it, each drawn with an arrow pointing toward it: a depressed local economy, the local community itself, and shared pain points — a problem that many people in the community feel in common, not a private individual complaint.

An arrow labelled "Design Thinking" — a structured process for understanding a problem from the perspective of the people actually experiencing it — leads from "The Problem" into a second, larger circle labelled "Idea / solution."

This second circle is fed from two directions. From below, an arrow labelled "Local Contributors" feeds in, and beneath the diagram, this label is broken out into its specific components: the local community itself; individual learners; volunteers, described specifically as mentors and guides; sponsors and local partners; and investors and government. From above, a second arrow labelled "Informational Resources" feeds in, broken out beneath the diagram into: local knowledge and culture; open resources freely available online; and what's labelled "smart micro-content" — the bite-sized, immediately applicable content described back in Chapter Five.

From the "Idea / solution" circle, a further arrow labelled "Growth Frameworks & Mental Models" leads onward to a final box, labelled "Homegrown innovative product/service." Beneath the diagram, this arrow's label is broken out into the five specific frameworks: Market Thinking, User Thinking, Business Thinking, Project Thinking, and further frameworks left open-ended with "and more."

And then — this is the detail that matters most, looking back at this diagram now — arrows lead out of the final "Homegrown innovative product/service" box, in four separate directions: to government, to local partners, to the local community, and to investors. The loop closes. Read as a whole, the diagram isn't only describing a learning mechanism. It's describing a complete economic loop: a community learns, builds something real together, and that real thing generates value that flows back out to the specific people and institutions connected to it — the same community it came from, plus partners, government, and investors alongside them.

In a real alpha training cohort — a small early group of participants who specifically wanted to learn product management by building something real, rather than studying it abstractly — the frameworks and process described above were applied to design Owmi, a platform aimed at a genuine, documented problem: unreliable access to clean, drinkable water among stay-at-home residents in Lagos. Owmi combined a location-based chatbot, built in a style similar to WhatsApp, with a companion app, connecting residents to nearby, trusted, treated-water sources.

This came directly out of real interviews conducted with Lagos residents. One woman, Nnenna, 26, from the Festac area of Lagos, described her situation this way: "When there is no power we cannot pump clean water at home, and the water we buy from neighbours has a funny taste and is coloured. We cannot drink it or use it to cook." Another resident, Gloria, 30, from Satellite Town, owned a private borehole for pumping water but still had to separately buy water safe enough to drink: "It is stressful having to go every time, someone bringing cold water to the house would be bae!" A resident named John, 28, described buying three separate bags of "pure water" — small sachet-packaged drinking water, common in Nigeria — every day just to have enough safe water for drinking and cooking, calling the ongoing cost significant. Another resident, Paul, 27, described going through three 25-litre jerry cans of water a day just to cover cooking and bathing needs.

Owmi was developed into a fully worked-out concept: sketched chatbot conversation flows, working no-code prototypes tested directly with real users over WhatsApp, wireframed app onboarding screens, and a complete business model — revenue planned from installation and treatment fees, delivery fees, and a percentage of in-store water sales at partner locations; costs planned around human resources, partnerships, and physical materials. The pitch material describing Owmi states plainly, without dressing up its actual state at the time: "Owmi is currently being built out and the apps are being developed by learners." It was never presented as a finished, fully scaled product.

Owmi's purpose was narrower, and more honest, than demonstrating that the whole system worked end to end. Its actual purpose was to show that a group of people, while genuinely learning, could apply the frameworks to build something that created real value for the people it served and real income potential for the people who built it. At that specific, smaller scale, it succeeded. It was not continued past this stage, and the reason for that is stated plainly here rather than left vague: the product required substantial ongoing physical, in-person operational work — water testing, delivery logistics, on-the-ground relationships with individual vendors — at a point where the broader direction of the work had shifted decisively toward tech and digital products that didn't carry that same operational weight.

Demonstrated once — not continued

The work continued under a new brand, Growth Clinic, positioned plainly in its own materials as: "a platform designed to crowdsource Nigeria's ingenuity to solve our challenges locally while enabling shared prosperity." The stated model: use the same Growth and Innovation System to help build sustainable social-impact businesses that helped individuals learn while solving a real, shared local problem — with participants owning a stake in whatever they built together, and earning as it grew, in a way meant to translate directly into shared prosperity for the surrounding community as well.

Growth Clinic's documented business model, stated in full: it targeted undergraduates, fresh graduates, and pre-seed-to-Series-A stage startups as customers, and generated revenue through learning delivered as a paid service (priced between roughly ₦8,500 per person for large groups and ₦25,000 for individuals), through talent placement and consultancy fees (20 to 30 percent of a hire's salary or fee), and through community-membership and profit-share arrangements. As market justification, Nigeria's National Universities Commission's 2017 figures were cited directly: roughly 1.7 million students enrolled across Nigerian universities at the time, with over 250,000 joining the national labour force annually.

A sub-brand, Community Staples, was subsequently built specifically to try to reach a large enough network of communities for the underlying concept to have somewhere to land and operate at real scale. This did not succeed in finding that audience.

Growth Clinic wound down at the end of 2025. The stated cause, understood directly by the person who built it, without independent outside verification because none exists: the business could not find or reach the right customer. And looking back at exactly how that happened, two separate, compounding shifts explain most of it.

Tested twice with real clients — wound down end of 2025

The first shift was away from the original placement model and toward selling training directly. Devcenter's original model — described fully in Chapter One — was to place skilled people into real, paid client work and take a share of the value that generated. Growth Clinic's model, by contrast, was to sell training programmes directly, priced per person, to whoever was willing to pay for them upfront. These look similar from a distance, since both involve people learning inside a structured system, but they are structurally different businesses. One is aligned with a real economic outcome on both sides: the learner ends up with paid work, and the business gets paid specifically for making that match happen. The other is aligned with nothing except whether someone is willing to pay in advance for the promise of getting better at something later.

This shift didn't come from sitting down and deliberately weighing which model was actually stronger. It came from chasing the first clear signal that looked like proof. The AFF engagement, described in Chapter Six, had started out as testing — a chance to run the training material in front of a real cohort for the first time — and the simple fact that it generated payment felt, at the time, like the market directly telling me what it wanted. That signal got built on, without being weighed carefully against what was already working inside the original Devcenter model.

Underneath that first shift sat a second one, not separated out clearly until putting all of this material together now. Maliyo Games, the engagement that followed AFF, was a real company — a business client, the same fundamental shape of customer Devcenter had always served through its original matching model. At some point after that, the focus moved toward individual people paying for training directly, rather than companies paying for outcomes. That's a different sales motion entirely, with different underlying economics, different trust requirements, and a customer — an individual person — with far less financial room to take a bet on their own future improvement than a company generally has.

Two pivots, happening close together, compounding each other in the same direction: away from placement and toward training sold as a standalone product, and away from companies as customers and toward individuals. Either pivot alone might have been survivable on its own. Together, they moved the business about as far as it could get from the shape that had actually worked at Devcenter in the first place. The people Growth Clinic ended up selling training to didn't primarily want training. They wanted income. The original Devcenter model gave people income directly, as the entire point of engaging with it at all. The later Growth Clinic model asked people to pay upfront for the mere possibility of income later — a much harder thing to sell, especially to people who don't have much financial room to spare for a bet that might not pay off.

Alongside this shift in the underlying business, the way the system was visually explained also changed, and it's worth being precise about exactly what changed and why.

A later version of the same diagram shows a circle divided into three equal slices, arranged around a small central circle labelled "Growth & Innovation System." The three slices are labelled Thinking Frameworks, Local Contributors, and Smart Micro-content. Underneath this pie chart, each slice is broken out further: Thinking Frameworks lists Design, Project, and Market Thinking, with "and more" left open; Local Contributors lists local community, local knowledge and culture, and local partners; Smart Micro-content lists bite-sized tasks drawn from real-world projects and problems, and summarised guides drawn from open online resources.

Compared against the fuller diagram described in Chapter Eight, this version is missing the entire right-hand side of the original picture. There is no "Homegrown innovative product/service" box. There are no arrows leading back out to government, local partners, the local community, or investors. What remains is only the learning mechanism itself, isolated, presented as though it were the whole system on its own.

I know now why that happened, and it wasn't a considered decision to specifically cut the economic loop out of the picture. Nobody sat down and judged the right-hand side of the original diagram less important than the left. What actually happened is that almost nobody who was shown the original, fuller version understood it. There were too many arrows, too many boxes, too many words crammed into each one, for someone encountering it for the first time to follow. That was frightening in a specific way — not simply that people weren't impressed by it, but a real fear of losing the chance to communicate what had actually been built at all, because nobody could follow the diagram long enough to actually understand it. In response, a designer and illustrator was brought in specifically to help make the idea more legible. They succeeded completely at that specific goal. What wasn't noticed at the time was that legibility and completeness were pulling in opposite directions, and the piece that quietly went missing in exchange for the legibility was the one piece that made the whole system more than just a method for learning faster.

A separate, related diagram from the same later period showed a three-step progression, labelled directly: Community, where people with shared goals and shared pain points come together to learn and create; Shared Economy, where that group, building and creating for themselves, conceives its own shared wealth; and Ecosystem, where the resulting shared economy enables other people around the original community to grow and participate in that shared wealth too, starting a self-sustaining loop. This three-step progression genuinely kept the economic dimension of the idea visible, even as the more detailed pipeline diagram lost it — which is worth noting honestly, since it means the loss described above wasn't total or universal across every version of the materials from this period. It was inconsistent, present in some places and missing in others, rather than a single clean edit applied everywhere at once.

In 2025, a whitepaper was produced titled From Knowledge to Judgement, re-articulating the same underlying insight described throughout this account — that knowledge and judgement are genuinely different things, and that judgement specifically requires deliberate, high-volume, fast-feedback practice — using new vocabulary layered on top of the same underlying structure. It proposed a name for the whole system: the Human Operating System.

The paper organised the idea into three parts. Instructional Deconstruction renamed the same skill-decomposition process described in Chapter Five into a formal "Career Recipe" format: a compressed, five-part description of a single executable professional skill — its domain, its name, the specific trigger condition that tells you to use it, the minimum correct sequence of actions, and the expected outcome of doing it correctly — deliberately constrained to be readable and usable within about thirty seconds. Thinking Frameworks carried forward the same five domains described in Chapters Six and Seven — Design, Business, Market, User, Project — unchanged from their original 2018 form. The Execution Loop proposed combining real-world execution tracking with AI-generated scenario practice, intended as a next-generation version of the working virtual many-to-many interaction that Frintern had identified as its missing piece back in 2018, described fully in Chapter Five.

Two specific tools were described in the material used to produce that whitepaper as though they were live, working products already available to real users: SYD Protocol, intended to track and reward a person's real-world execution over time, and Slop Runner, intended as an AI-driven scenario-sparring engine for building judgement through practice. Neither tool had actually reached a real user outside its own construction. Both were exploratory builds, made to help externalise and think through a concept that existed clearly enough conceptually but hadn't yet found a working, tested shape — not built to solve a demonstrated problem for a specific real person, and never shown to anyone outside the process of building them. Stating this plainly here matters, because the original version of that paper described both tools as live, and that description was not accurate.

Never reached a real user — exploratory only

Looking back at the name chosen for this version of the system — Human Operating System — it no longer sits right. "Operating system" implies continuously running, largely automated infrastructure, which is exactly what the AI-driven layer (SYD Protocol and Slop Runner) was meant to become but never actually did. Almost everything genuinely proven across this whole nine-year account — the 2018 TTLS pilot, the AFF and Maliyo Games engagements, the Owmi build, the community observations underneath the frameworks — happened through direct, human-delivered work, not through automated infrastructure. The name put the emphasis in exactly the wrong place relative to where the actual evidence sits. For that reason, the name has been dropped, and no replacement has been chosen yet.

A current, ongoing piece of work, separate from the arc described above but genuinely connected to it, is called LORE. It's aimed at organisational knowledge transfer — specifically, capturing what an experienced employee actually knows, in terms of judgement and decision-making, before they leave an organisation and take that judgement with them, without requiring the employee to sit down and try to document their own reasoning directly.

The word "recipe," used throughout the earlier parts of this account and inside the 2025 whitepaper's "Career Recipe" format, has a longer and more personal history than that specific whitepaper. Understanding computer algorithms as recipes — precise, ordered sequences of steps that reliably produce a given outcome — came first. Understanding people's own mental models the same way, as a kind of personal recipe for how they approach a given kind of problem, came somewhat later, independently, and predates the 2025 whitepaper's formal "Career Recipe" terminology by some time. The whitepaper didn't originate this way of thinking. It simply gave an existing, older habit of thought a more formal name.

LORE's underlying method for extracting judgement is built specifically around a documented idea from cognitive psychology: that an expert's actual decision-making policy can be inferred from the pattern of decisions they make across many varied real cases, without ever needing to ask them to explain their reasoning directly — because people are demonstrably far more consistent in how they actually apply a policy than they are in describing that policy out loud. This is the same underlying insight first observed directly in the Five-Star Dilemma, described in full in Chapter Seven, arrived at independently and much earlier, in 2016, without the formal psychological vocabulary attached to it at the time.

LORE is not a success case. It is currently being tested, and its outcome is genuinely unresolved. The first version of the product received a specific, real, unflattering piece of feedback: a human-resources manager who reviewed it asked, in effect, why they would use LORE at all, when they could simply do the same knowledge-transfer work manually themselves. That objection wasn't deflected or explained away. It directly triggered a full revamp of the product, currently in progress, built specifically to answer that exact objection rather than to defend the product's original design.

Live now — unresolved

A separate, internal test of the underlying extraction method — one practitioner working through the full process from start to finish — produced a result that was honestly diagnosed rather than presented as a success. The output was judged "correct but generic," and that judgement was traced to two specific, identifiable implementation gaps rather than left as a vague, unexplained sense that something wasn't working: first, the system's method for generating relevant decision cues relied entirely on the practitioner's own self-description of their work, with no independent check against it; second, a data field in the underlying system, specifically meant to distinguish subtle, hard-to-verbalise judgement signals from more explicit, easily stated ones, existed in the design but was never actually being used anywhere in how questions were generated for the practitioner.

This thread — knowledge-to-judgement work, currently being tested through LORE — is something genuinely worth continuing on its own terms, independent of how the rest of the arc described in this account resolves. It isn't necessarily a direct continuation of the earlier work, and it isn't an attempt to bring back the "Career Recipe" format or branding specifically. It may turn out to be a derivative of everything described above, or it may turn out to be its own separate thing entirely. Right now, everything in this specific thread is being actively tested and shared informally, under the working name of a "cookbook" rather than any more formal or finished label.

Four distinct attempts — Learn by Doing, Frintern, Growth Clinic together with Community Staples, and now LORE — have pursued essentially the same underlying insight across nine years, in four different forms, aimed at different kinds of people and different business models each time. Two of these four demonstrably worked at the level of the actual underlying mechanism and still failed commercially: Frintern's TTLS pilots produced a real, measured, specifically dated result, and the business still didn't sustain itself past that point; Growth Clinic's frameworks were independently validated through two separate paid client engagements, and the business still couldn't find or keep the right customer. One attempt — SYD Protocol and Slop Runner — never actually left the exploratory stage, and is described that way here honestly rather than dressed up as something more finished. One — LORE — is live, real, and genuinely unresolved right now, having already survived one specific, real piece of external rejection and one honestly diagnosed internal failure, responding to both with a traceable, specific fix rather than retreating into vaguer, more comfortable claims.

Running underneath every single one of these four attempts is the same governing idea, first noticed directly in 2016 through the Five-Star Dilemma described in Chapter Seven: people are far more reliable in what they actually do, case by case, than they are in explaining what they do if you simply ask them. Every framework, every recipe format, every version of this system across nine years has, at bottom, been an attempt to build something around that single observation.

Two genuinely open questions remain, and this account doesn't resolve either of them, because neither is actually resolved yet.

The first is whether the original economic engine — a community deliberately upskilled, then matched directly to real paid client work, with a share of that real value captured as the business model, the way Devcenter originally worked in Chapter One — was the piece that quietly went missing somewhere between the raw diagram in Chapter Eight and the simplified one in Chapter Eleven, and whether rebuilding that specific engine, rather than any particular framework or recipe format, is the actual unresolved thread worth picking back up.

The second, entirely separate question, is whether the knowledge-to-judgement work currently being tested through LORE is worth continuing simply on its own merits — because it's a genuinely interesting problem to work on, regardless of whether it ever reconnects to the community-and-shared-prosperity thread that runs through the rest of this account, or whether the two threads eventually turn out to be the same idea wearing two different faces, the way so much of this account has already turned out to be one idea returning under a series of different names.

Neither question has an answer yet. This account exists to make sure both questions are being asked clearly, with the full record in front of them, rather than being asked again from scratch the way the same underlying question has already had to be asked several times before.