The Everything Ecosystem Methodology

A structural analysis framework for building, classifying, and managing entities within an ecosystem.

This methodology is under active development. The core architecture and principles described here are stable, but specific systems, schemas, and operational behaviors are still being refined. Elements are subject to change as the methodology matures through real-world application.

What This Is

The Everything Ecosystem methodology is a system for taking any idea, product, tool, company, or ecosystem and running it through a structured process that determines what it is, what it needs, where it sits, and how it relates to everything around it.

It works in two directions. Applied analytically, it maps the structure of something that already exists — a company, an organization, a set of interconnected projects. Applied creatively, it guides you in building something new and determining its place within a larger structure. The same framework, the same questions, the same schema apply in both directions. If the framework can accurately describe the structure of Google, Meta, or Tesla when applied analytically, it can also guide someone building their own ecosystem when applied creatively.

The methodology produces entity profiles — structured documents that fully describe what an entity is, where it stands, what it needs, and how it relates to everything around it. Every mode of operation (discovery, analysis, review, development, decision) is a process that results in creating, populating, or updating these documents.

The Core Insight

Underneath this methodology is a general structural analysis approach. The act of taking any entity and asking five questions — what are its constituent parts, how are they organized, how do they relate to each other, what is the lifecycle of each part, and what is the lifecycle of the whole? — is not limited to business. It applies to governments, biological systems, celestial structures, and any domain where structure exists.

The Everything Ecosystem is what happens when you instantiate that general methodology for the business domain. The three pillars — product, brand, and business — are the business-domain answer to “what are the constituent parts of a correctly formed commercial entity?” Other domains would have different constituent parts but the same underlying structural questions.

A System of Systems

The methodology is not a single process or a checklist. It is an interconnected set of systems, each with its own purpose:

The Idea Dump System manages where ideas live and what states they hold. It functions as a ledger — recording whether ideas are active, implemented, or archived. Ideas enter, accumulate, and resolve: either forward into design and implementation, or sideways into an archive of decisions not taken. The idea dump can reach an empty state, and that’s healthy — it means everything has been acted on.

The Routing System handles transportation — moving ideas between dumps across the entity hierarchy. Ideas route from one dump to another (never directly to implementation), and they can flow both upward and downward. An insight surfaced while working on a child entity can route up to the parent ecosystem. An ecosystem-level idea can route down to the specific entity it belongs to. Routing timing is configurable — immediate, batched, or visible as a queue for the person to manage.

The Diagnostic System observes all other systems and surfaces insights. It detects implementation lag (ideas sitting too long without action), clustering patterns (many ideas pointing to the same sub-area), and inactivity (domains that could use attention). It functions as a strategic planning tool — surfacing what needs to get done, what ideas are lacking implementation, and the relationships between parts that need attention to achieve stated goals.

The Design & Specification System is the layer between the idea dump and implementation. When an idea graduates from the dump, it enters formal design work — specifications, architecture, design decisions — before being built.

The Implementation System handles execution — taking specifications and producing shipped artifacts.

These systems have directional relationships. The routing system serves the idea dump. The idea dump feeds design and specification. Specs feed implementation. The diagnostic system monitors everything. And the provenance chain — a multi-hop tracking system — crosses all of them, letting you trace any idea from its origin to its end.

Structural Primitives

The framework is built on structural primitives — questions and categories that hold true regardless of the entity, the industry, or the context.

Every entity is examined through three pillars: product (the made thing), brand (how it’s perceived), and business (how it sustains itself). Not every entity needs all three — an open source tool may correctly exist as a product alone — but the framework demands conscious awareness of which pillars are present, absent, and why.

Every field in every entity profile has a value or a status. The statuses (N/A, not yet determined, planned, in development, documented, under review, consciously deferred) are themselves structural primitives. A blank field is a failure of the framework. A field marked “consciously deferred” is the framework working correctly.

Every entity has a lifecycle (ideation, documentation, implementation, production), a classification (ecosystem, subsidiary, product-within-company, open-source-tool, internal-tool, shared-infrastructure, unplaced-idea), and relationships to other entities (horizontal adjacency, vertical integration, diagonal movement, radial, loose affiliation, external dependency).

Entity profiles are recursive. A company-level profile is composed of entity profiles at the pillar and product level. The schema stays the same at every depth.

The Idea Lifecycle

An idea’s life crosses multiple systems. It originates in an idea dump. It gets triaged — assigned a status from an extensible vocabulary (observation, suggestion, decision, request, blocked, deferred, and others as needed). If it’s in the wrong dump, the routing system moves it. When ready, it graduates to design and specification, then to implementation, then to production.

Ideas can also move backward. A shipped feature that gets pulled back due to low adoption or bad timing enters regression — moving out of production, with documentation archived. The methodology tracks this full lifecycle through provenance chains: every idea knows where it came from, where it’s been, how long each transition took, and where it ended up.

Archiving can happen at any lifecycle stage. An idea can be archived from the active dump (decided against before specs), from specification (designed but not built), from implementation (built but not shipped), or from production (shipped but regressed). Each carries different provenance and different meaning.

Three Interacting Schemas

The methodology works with three types of structured profiles:

Entity profiles describe projects, products, organizations, and ecosystems. Ten sections covering identity, classification, pillar assessment, mission alignment, relationships, visibility, child entities, lifecycle, documentation audit, and changelog.

Person profiles describe the humans involved. A person is the root node above the ecosystem level — a person has ecosystems, ecosystems have entities. The person profile covers identity, capacities, project relationships (with nature of commitment, emotional investment, time horizon, and intended outcome), relationships to other people, visibility, lifecycle, documentation audit, changelog, and an open context section for anything that doesn’t fit elsewhere.

Position schemas describe structural roles within organizations. A position exists whether or not anyone fills it. It has scope of authority, responsibilities, institutional relationships, and constraints. When a person fills a position, the relationship captures the distinction between personal-capacity and positional-capacity actions and resources.

These three schemas interact: persons fill positions, positions belong to entities, and persons relate to entities both through positions and directly.

Session Management

The methodology adapts to how someone works. At the start of every session, it calibrates to the person’s intent — whether they want to capture ideas, focus on one thing, work in parallel across entities, explore the framework, return after an absence, or flow between modes during a single sitting.

Three engagement modes govern interaction style: guided (walk through every decision), autonomous (produce the best assessment, present for correction), and exploratory (surface possibilities without converging). Engagement mode is granular — different aspects of the same entity can operate in different modes.

A rolling session log captures what happened during each work session: intent, entities touched, artifacts produced, and recommended next session.

Sustaining Behaviors

The framework includes behaviors that keep the work connected to its purpose:

Value articulation reminds the person what the structure is building toward — on entry (why this is worth doing), mid-conversation (why this step matters), and on completion (what you now have).

Progress inventory shows what has been produced and what it enables at any stopping point. The value curve is front-loaded — the first outputs deliver disproportionate structural clarity.

Finish line visibility defines what “done” looks like for a given entity and shows the distance from the current state.

Together, these create three complementary navigational views at any point: what I have (progress inventory), what’s missing (documentation audit), and what done looks like (finish line).

Who This Is For

This methodology is a tool for systems thinkers. It is useful to anyone in a position that requires strategic thinking about interconnected entities — CEOs building ecosystems, developers architecting products, product managers mapping portfolios, or anyone trying to understand the structure of something complex and make deliberate decisions about how to build or change it.

The diagnostic system in particular serves strategic roles: surfacing backlogs, identifying which domains need attention, showing the relationship between parts that must be addressed to achieve stated goals, and helping organize work across daily, weekly, and monthly planning horizons.

Where This Is Going

The Everything Ecosystem methodology is being developed as both a standalone framework and the product specification for Ostr-itch — a software product that generalizes this structural analysis approach to all domains. The methodology is simultaneously theory (the structural analysis approach), product spec (what Ostr-itch implements), and practice (how Ostr-itch’s own development is organized).

The methodology is currently implemented as an AI-readable skill that can be used by AI agents to guide structured analysis and entity profiling. As it matures, it will be refactored into a modular skill family with specialized skills for each system (idea dump, routing, diagnostics, session management, and others).

For updates, discussion, and related writing, visit TCJ Cafe.

The Everything Ecosystem methodology is developed by Torian Johnson. This document describes the methodology’s current state and is updated as the framework evolves.