Reality, Freedom and Responsibility: The THY-REALITY 90-Day Plan

The developmental arc ends with a verifiable step, not a new ideology

Across the first developmental arc, THY-REALITY repeatedly separated reality from narrative, freedom from mere preference, community from coercion, and decentralisation from a pleasant name for another concentration of power. This article must apply the same discipline to the project itself. If, after 107 articles, we still need a perfect theory before taking one small step, we have built a new form of procrastination.

The first rule of the final plan is therefore that it is not designed to prove the whole THY-REALITY philosophy. A 90-day project cannot prove Natural Law, polycentricity or the universal superiority of any ownership model. It can test a narrower question: can we reduce a specific dependency, increase a capability or meet a shared need more reliably, transparently and voluntarily than we do today?

The final criterion is thus the same as the first one: reality has the right to correct our map. If the pilot does not work, do not become angry with reality. Correct the plan.

“Personal Dependency Audit: What Does My Life Actually Depend On?” mapped personal dependencies, “Local Resource Map: What Do We Already Have Around Us?” mapped local resources, “From Five People to the First Local Core” formed a first working core, and “Transition Without Collapse: Building Parallel Institutions” developed a safer transition method. Now use those four steps to choose one clear task. A good 90-day project addresses a real problem but is not so large that the whole system must be transformed before a first result can even be measured.

Examples might include a backup communication route for a small group, a local repair or tool-sharing service, a small purchasing or logistics circle, verification of access to a local resource, a narrowly bounded mutual fund, or a pilot for an additional supply route. In health, energy, water, security and other critical domains, however, the 90-day objective will often be preparation, testing or a bounded pilot, not the reckless transfer of an entire function.

If the task cannot be described in one sentence without phrases such as 'change the system', 'wake people up' or 'become independent', it is probably still too broad. Reduce it until it is clear what will be different after ninety days.

Day 0: record the baseline before trying to improve it

Without a baseline, almost every project can look successful three months later because memory adjusts to expectation. Before starting, record the present state. What exactly is the need? How is it handled today? What time, money, people or routes does it require? Where is the single point of failure? What happens if the main provider, person, account, device or supply route fails?

Then record the assets that already exist: people, skills, space, tools, contacts, alternatives and constraints. The baseline does not need to become a perfect research project. It only needs to be good enough that Day 90 permits a meaningful before-and-after comparison. For qualitative goals, define what improvement would look like: faster access recovery, less dependence on one person, or a clearer accountability process.

This is protection against self-deception. Measure first, then move.

A goal should be concrete enough that different people understand it in roughly the same way. Goal-setting research has long shown the value of specific, challenging but feasible goals, while modern evaluation frameworks require clarity about what will be measured and what standard will be used to judge performance.

Use three kinds of measures in this article. An implementation measure tells you whether the agreed steps occurred. An outcome measure tells you whether the real situation improved. A safeguard measure tells you whether the improvement created a new risk, concentration or exclusion. A project that lowers one cost while creating one irreplaceable person or a serious safety gap is not automatically a success.

A few measures that can change a decision are enough. Twenty indicators that nobody will use do not create more control; they create a larger spreadsheet.

Responsibility needs a name; authority needs a boundary

Every important task needs a person who makes sure it moves. That is not the same as appointing a permanent leader. “How Do We Make Decisions Without a Permanent Ruler?” and “When Does a Delegate Become a Ruler?” already distinguished a bounded mandate from an autonomous centre of authority. For each major step in the 90-day plan, write down who is responsible, who assists, what the responsible person may decide alone, and when a decision must return to the group.

Responsibility without authority produces excuses; authority without accountability produces power without feedback. Both sides must be visible. If one person controls money, records, access and communication, split the functions or create review. If the project is personal, identify at least one person who knows what you are trying to do and can ask a month later whether anything happened.

The point is not bureaucracy. It is to prevent the sentence: 'I thought somebody else was going to do it.'

Days 1–30: understand, prepare and run the smallest useful test

The first thirty days are not about proving the greatness of the project. They test whether the problem is understood at all. Confirm the baseline, verify key contacts, identify legal and safety constraints, define the minimum pilot scope, and clarify which existing routes will remain untouched during the test.

By Day 30, something should exist that did not exist on Day 1: an agreement, a test service, a verified fallback route, a list of real users, a basic protocol or a small working prototype. Where possible, test it with few people and low consequences of failure.

End the first month with one question: is the problem still what we thought it was at the beginning? If not, changing direction is not failure. It is the purpose of a pilot.

The second month is for real use. Do not seek only people who already agree with you; include someone likely to notice an inconvenience the founding group overlooked. Record time, cost, errors, bottlenecks, the number of people who actually use the solution, and cases where somebody had to intervene manually or fall back to the old route.

Keep the operating rhythm light: one short weekly review, an open task list and one place where important decisions are stored. Meetings are not outcomes. If the weekly review does not lead to a decision, removal of a blocker or learning, shorten it or remove it.

This phase also reveals whether the new route is genuinely independent. If the fallback depends on the same people, account, server or supplier as the primary route, record that as a shared point of failure rather than a second option.

Days 61–90: test resilience, not only smooth operation

The third month is not merely more of the same. It asks what happens when conditions are imperfect. Where safe and lawful, simulate an ordinary disruption: a key person is absent, a delivery is late, a price changes, a device fails or a user makes a mistake. Critical systems should not be deliberately disrupted in dangerous ways; use tabletop exercises, test environments or other bounded methods instead.

Test the human side too. Can a new person understand the process? Can somebody leave without taking the whole function with them? Can a decision be challenged? Has hidden labour accumulated on one exhausted person? Did we build capability, or merely a new dependency?

The Day 90 objective is not perfection. It is enough real evidence that the next decision is no longer based only on feeling.

Use if–then rules for predictable obstacles

Good intentions often fail at ordinary points: time disappears, conflict appears, somebody forgets, money is delayed or the first result disappoints. Research on implementation intentions suggests that advance if–then plans can help bridge the gap between intention and action.

Write a few such rules for the project. If weekly cost crosses the agreed limit, pause new purchases and review the model. If the key person cannot participate for two weeks, the named backup takes the task. If the pilot creates a safety or legal concern, return to the previous route and document the incident. If nobody uses the service for three consecutive weeks, re-examine the problem rather than the marketing.

These rules reduce the temptation to improvise only in directions that protect the original idea.

A project that is allowed only to expand is no longer an experiment. “Transition Without Collapse: Building Parallel Institutions” therefore required rollback, and this article brings that discipline into the personal and community plan. Before starting, define what would be serious enough to stop, reduce or return the project to preparation.

Reasons might include safety, legality, disproportionate cost, unreliability, lack of voluntary participation, conflict of interest or excessive dependence on one person. In small projects it can be difficult to admit that an idea performed worse than expected because identity and relationships become attached to it quickly. A pre-agreed boundary makes the decision less personal.

Stopping is not necessarily failure. If a small pilot cheaply teaches us what should not be scaled, it has performed an important function.

On Day 90, run a retrospective that can change the decision

The closing review is not a celebration report. Compare the baseline with the result, review the measures and ask: what did we intend to do, what actually happened, why was there a difference, and what would we do differently next time? Meta-analytic research on debriefs indicates that structured reflection after action can improve later performance; the point of the retrospective is to turn experience into a better next cycle.

Finish by choosing one of four decisions: continue if the solution works at its current scale; adapt if the problem is real but implementation is not yet good enough; stop if benefits do not justify cost or risk; scale only if the measures are met and scaling will not destroy the safeguards that made the pilot work.

Scaling is not a reward for effort. It is a new experiment at a larger scale, with new failure modes.

The THY-REALITY 90-day sheet and what comes next

The whole plan fits on one page with twelve fields: 1) problem or need, 2) baseline, 3) 90-day outcome, 4) responsible person, 5) contributors, 6) existing resources, 7) Days 1–30, 8) Days 31–60, 9) Days 61–90, 10) success and safeguard measures, 11) if–then and rollback rules, 12) retrospective date and the continue/adapt/stop/scale decision.

This is the end of the first the articles from “Perception Is Not the Same as Reality” through “Reality, Freedom and Responsibility: The THY-REALITY 90-Day Plan” developmental arc, not the end of THY-REALITY and not the end of learning. After this article the portal can expand through deeper branches, new evidence, practical tools, local cases and corrections. But the foundational cycle is complete: observe reality, verify claims, protect freedom and responsibility, cooperate without unnecessary concentration of power, and test some of it in the world.

If the project has not succeeded after ninety days but you know precisely why, which assumption failed and what the better next step is, you have progressed. If it succeeded, do not turn it into doctrine. Measure the next constraint and start another cycle. Reality remains the final authority after the final article too.