The Solynth Web hero infographic
The Solynth Web connects project governance with the systems that perform, verify, publish, and commercialize the work.
An AI project-operating system for coordinated, controlled, and shared intelligence
21 August 2026
The Solynth Web connects project governance with the systems that perform, verify, publish, and commercialize the work.
Working concept paper — 20 August 2026
Copyright © Robert Harvey Curtis (rhc)
The Solynth Web is a proposed animated model of a project as a living, reconstructable web rather than a fixed schedule drawn once and progressively invalidated by reality. Its center represents the project target and eventual go-live or customer sign-off. Radial spokes represent dimensions or work domains. The curved task cells between spokes represent main tasks, subdivided into atomic subtasks. Color expresses lifecycle state: gray for defined future work, orange for work in progress, blue for completed work, green for go-live and customer acceptance, and yellow for protected contingency. The web can gain tasks, subtasks, and spokes through governed scope change while preserving an auditable history of how the project evolved.
The concept also distinguishes three kinds of actors: project participants who perform manual or governance work; human AI coordinators who direct artificial-intelligence workers while also performing human work; and AI actors that execute bounded tasks in parallel. This distinction is central. Traditional project management often encounters diminishing or negative returns when managers respond to delay by adding people, because onboarding and human communication costs grow rapidly. The Solynth model proposes holding the human coordination surface relatively stable while allowing a governed AI execution layer to expand within measurable limits.
This paper compares the Solynth Web with Gantt charts, PERT/CPM networks, Kanban boards, burn-up charts, Design Structure Matrices, radar charts, Critical Chain buffer management, and emerging human–AI orchestration research. The preliminary conclusion is that the Solynth Web is best understood not as a replacement for those methods but as a synthetic operational view that combines several of their strengths. No exact prior method was found in this initial review. That is evidence of possible novelty, not proof of legal or academic originality.
Most project visualizations answer one or two questions well:
Real projects require all of those questions to be answered together. They also change while being executed. New information produces new tasks, formerly simple tasks divide into subtasks, work domains appear or disappear, and the original schedule becomes a historical artifact rather than an accurate description of the project.
The Project Management Institute describes project network diagrams as representations of relationships among schedule activities, while PERT and CPM concentrate on network logic and critical paths. Those methods are excellent at dependency reasoning, but they are not designed primarily as animated, high-level lifecycle portraits. PMI: PERT, CPM and precedence diagrams
Gantt charts make time, duration, milestones, and task overlap legible. Microsoft describes them as a way to define project tasks and show when they will happen. Their weakness is not that they are ineffective; it is that a large, rapidly changing project can turn the chart into a long and difficult-to-read wall of bars. Microsoft: managing the project lifecycle
Kanban makes workflow state and work-in-progress limits visible. Burn-up charts make completed work and changing total scope visible. Atlassian explicitly notes that a burn-up chart plots completed work against total scope and therefore exposes scope change. Neither view, by itself, shows the structural shape of the project, the actor model, the contingency reserve, and the changing topology of tasks and work domains. Atlassian: burn-up charts
The Solynth Web begins from a different question:
Can a project be shown as a living system whose structure, work state, actor capacity, governed scope growth, and remaining contingency are visible in one animated form?
The center is the project target, not “work already completed.” It begins in a pending state, passes through a go/no-go decision, becomes blue when the decision to proceed is complete, and becomes green during go-live and customer sign-off. The center therefore represents the final convergence of the project rather than the chronological starting point.
Spokes represent project dimensions, domains, workstreams, systems, or other measurable divisions. Their labels may exist in the underlying data without appearing permanently on the overview. A spoke may be added when a new work domain is formally recognized. A spoke may also be consolidated or retired. This makes the web structurally adaptive.
The curved connectors between adjacent spokes are main tasks. Each main task can be refined into several visible subtask segments. Subtasks progress independently and sequentially from gray to orange to blue. Different tasks activate at inner, middle, and outer positions, producing a distributed “sparkle” rather than an inaccurate center-out or perimeter-in progression.
The web is therefore not a conventional radar chart. In a radar or spider chart, every spoke is a quantitative axis and distance from the center represents magnitude. The Solynth Web borrows the visual grammar of spokes and concentric structure but uses the spaces and curves between spokes as work-bearing cells. Conventional spider charts are mainly used to compare several dimensions in polar coordinates. Storytelling with Data: spider and radar charts
The current model uses a deliberately small state vocabulary:
| Color | Meaning |
|---|---|
| Gray | Defined future work |
| Orange | Work in progress, whether performed by a human or AI actor |
| Blue | Completed work |
| Green | Go-live, green-light condition, and customer sign-off |
| Yellow | Protected contingency reserve |
Color must always be paired with labels, counts, and accessible descriptions. The model should never rely on color alone.
In the present scenario, the project has an 80-day baseline, a 100-day governed delivery target, and an approved 120-day budget ceiling. Twenty yellow blocks around the periphery represent contingency days that remain protected unless formally consumed. Completion on day 100 leaves twenty days unused.
This resembles Critical Chain Project Management in one important respect: uncertainty is protected by pooled buffers rather than hidden padding scattered across individual activities. PMI describes Critical Chain as a schedule approach that considers both precedence and resource dependencies, while Critical Chain practice uses buffers to protect the project. PMI: Critical Chain buffer sizing
The difference is visual and operational. Critical Chain emphasizes a resource-feasible chain and buffer consumption. The Solynth Web places reserve visibly around the whole evolving project and connects its consumption to governed scope and lifecycle state.
This animated example is deliberately a strawman rather than a validated forecasting model. It demonstrates the proposed visual grammar: defined work, active human and AI work, completed work, governed scope additions, go-live, sign-off, and protected contingency. Its numbers and transition rules are illustrative and will be replaced by configurable parameters and evidence from real projects.
Static fallback: the interactive animation above requires a browser that permits embedded scripts. The complete simulator is contained in this file; no external asset is required.
The phrase scope creep is often used for any increase in work. That is too imprecise. If a change is reviewed, authorized, measured, and incorporated through change control, it is better described as an approved scope change or governed scope evolution. The Institute of Project Management similarly distinguishes uncontrolled creep from formally reviewed and authorized expansion. Institute of Project Management: scope creep
The Solynth Web assumes that some change is inevitable. It therefore does not pretend that the initial task list is complete. Instead, it makes four things visible:
Small changes may be accepted under delegated authority within agreed tolerances. Larger changes require stakeholder review. This is closely aligned with PRINCE2’s management-by-exception principle: lower levels operate within defined tolerances, while forecast breaches are escalated. PRINCE2 guidance describes tolerances across areas including time and scope and explains how minor scope changes may be handled without full escalation. PRINCE2: understanding tolerances
The web should therefore record not merely that a task appeared, but why it appeared, who authorized it, which tolerance or change threshold applied, and what happened to delivery forecast and contingency.
The present Solynth scenario distinguishes:
Orange work is therefore the sum of active manual tasks and active AI tasks. The number of active AI actors equals only the AI-owned portion of the orange work.
This actor model responds to the problem popularly associated with Brooks’s Law: adding human workers to a late software project can make it later because of onboarding, task indivisibility, and rapidly increasing communication overhead. The law is a qualified observation rather than a universal mathematical rule, but it correctly warns that human headcount is not interchangeable with productive capacity. Brooks’s Law overview and references
The Solynth hypothesis is not that AI coordination is free. Multi-agent research warns that agent communication can also create message congestion and performance bottlenecks. Survey of multi-agent orchestration architectures The proposed advantage is narrower: a stable human team may be able to increase bounded AI execution capacity with less incremental human-to-human coordination than would be required to onboard the same number of additional people.
Emerging research on human–AI teams is moving in a compatible direction. Masters and colleagues describe a manager-agent research agenda in which complex goals are decomposed into task graphs, work is allocated across human and AI workers, progress is monitored, and plans adapt to changing conditions. Their results also show that jointly optimizing completion, constraints, and runtime remains difficult. Masters et al.: Orchestrating Human–AI Teams
That research supports the relevance of the Solynth actor model but does not establish that the web visualization itself already exists.
The Solynth Web is not principally a retrieval-augmented generation system. RAG can supply grounded context from documents and databases, but retrieval is only one service inside the larger architecture. The proposed system is closer to an AI project-operating system: a governed coordination layer in which project plans, code, issues, databases, tests, APIs, operational evidence, content, organizations, and delivery channels remain connected and evolve together.
The working architecture includes:
The Model Context Protocol is relevant because it standardizes connections between AI applications and external systems, including files, databases, tools, and workflows. It is connective tissue, not the project model itself. Model Context Protocol introduction Likewise, repository issue APIs can expose assignments, comments, labels, milestones, and status to the orchestration layer. GitHub REST API for issues
The distinguishing ambition is closed-loop project operation. The same system that helps perform a task should update the plan, create or update the issue, record evidence, run the relevant tests, update the health state, expose the capability through its API, and refresh the Solynth Web. This does not eliminate human approval. It makes approval, provenance, verification, and effect visible.
The intelligence model uses the following established project vocabulary:
The compact expression is:
AI + NI → SI, governed by CI
The complementary Solynth metaphor is:
NI + AI = I³
The cube is not a literal physical law. It expresses the proposition that well-structured collaboration can be multiplicative rather than merely additive. A more disciplined engineering analogy is:
I(t+1) = g(t) · I(t)
where the amplification factor g(t) may be greater than one when useful feedback is occurring, but is deliberately constrained by Controlled Intelligence. Evidence quality, uncertainty, risk, reversibility, and validation should all affect the permitted gain.
The feedback mechanism has also been described as IASER — Intelligence Amplification by Stimulated Emission of Reasoning. NI stimulates AI; AI output stimulates further NI; the improved human contribution becomes the next AI stimulus. The analogy describes iterative amplification and positive feedback. It is a research hypothesis and design metaphor, not a claim of mathematically guaranteed exponential growth.
| Method | What it does best | What it usually does not show well | Relationship to the Solynth Web |
|---|---|---|---|
| Gantt chart | Dates, durations, overlap, milestones, baseline versus actual | Large-scale topology, evolving domains, compact actor view | Solynth sacrifices precise horizontal time positioning for a compact lifecycle portrait; a Gantt view should remain available underneath it. |
| PERT/CPM network | Dependencies, sequence, critical path, float | Dense live status, scope growth, contingency and actor scaling in one view | Solynth borrows graph logic but does not yet calculate or display critical path explicitly. |
| Kanban board | Workflow states, queues, bottlenecks, WIP limits | Whole-project topology, delivery reserve, long-term structural history | Orange task count functions like WIP, but the web adds structure, history, and project convergence. |
| Burn-up chart | Completed work versus evolving total scope | Task identity, dependency, resource ownership and topology | Burn-up is the closest simple comparator for managed scope growth; Solynth spatializes that growth. |
| Design Structure Matrix | Dense dependencies among components, tasks, or teams | Intuitive lifecycle storytelling and animated progress for general audiences | DSM could supply the dependency engine behind the web. MIT describes DSM as a square grid showing how every system element relates to others. MIT Sloan: Design Structure Matrix |
| Radar/spider chart | Compact comparison of several dimensions | Tasks, dependencies, actors, changing scope and time | Solynth reuses the radial visual grammar but assigns a fundamentally different meaning to its cells and animation. |
| Critical Chain | Resource feasibility, constraint awareness, pooled schedule buffers | Rich spatial picture of evolving scope and mixed human–AI execution | Solynth’s yellow perimeter resembles a project buffer but makes unused reserve and governed change visually prominent. |
| Traditional dashboard | Exact counts, trends, forecasts and exceptions | A memorable structural picture of the project as one evolving object | Solynth should consume dashboard data rather than replace it. |
The individual ingredients are not new:
The potentially distinctive contribution is their combination into one governed visual grammar:
In this preliminary search, no established project-management method was found that uses that exact combination. The closest precedents are a radar chart’s radial grammar, a network diagram’s task relationships, a burn-up chart’s changing scope, Kanban’s work states, Critical Chain’s buffer, DSM’s dependency density, and emerging human–AI orchestration systems.
This should be described as possible conceptual and visual novelty. A proper novelty claim would require a structured scholarly review, product search, and patent search using the final terminology and a precise formal specification.
The web will become credible only if it avoids being merely attractive.
Every position must mean something reproducible. If tasks jump when a spoke is added, the animation may look alive but destroy the viewer’s mental map. The layout algorithm needs rules for stable task identity, controlled reflow, and historical continuity.
The current prototype shows state and structure but not explicit predecessor/successor relationships. Those relationships must exist in the data model even if the overview hides them. On selection, the system should reveal upstream dependencies, downstream impact, criticality, and blockers.
A task is not necessarily equivalent to another task. Counts can mislead when one task represents minutes and another represents weeks. The model needs optional weighting by estimated effort, value, risk, cost, or duration.
One orange task per AI actor is a useful initial rule, not a universal law. Some actors may supervise several lightweight tasks; several actors may collaborate on one task; humans may perform work while also reviewing agent output. The actor-to-task mapping needs a formal concurrency model.
“Managed scope creep” should not become a rhetorical excuse for accepting every request. New work needs an authorization record, impact assessment, source, decision owner, tolerance classification, and effect on contingency.
The model must be compared against real projects. A visually pleasing simulation is not evidence that it improves forecasting, communication, or delivery.
The next version should expose parameters rather than hard-code a single story:
The modeler should be calibrated against telemetry from the projects and subprojects running across the Solynth Network: task creation, task refinement, completion time, actor assignment, AI invocation, review cycles, test results, defects, change approvals, contingency consumption, code changes, issue transitions, deployments, API health, content publication, and commercial outcomes. Simulated runs could then be compared with actual project histories.
Once enough data exists, the system could test questions such as:
The Solynth Web should not be marketed initially as a replacement for Gantt, PERT, Kanban, Critical Chain, or earned-value reporting. Its strongest position is:
A living project map that unifies state, structure, governed change, actor capacity, contingency, and project convergence—while retaining links to the detailed schedule, dependency, cost, and evidence systems beneath it.
That positioning is both ambitious and defensible. It acknowledges that established methods retain analytical strengths that a radial overview cannot duplicate. At the same time, it identifies a genuine gap: project teams still lack a compact and memorable way to see a changing project as one evolving object, particularly when human and artificial-intelligence actors are working together.
| Claim | Original or authoritative source | Independent corroboration | Status |
|---|---|---|---|
| PERT/CPM and precedence diagrams model project activity networks and relationships. | PMI | Project Management Academy | Verified established practice |
| Gantt charts emphasize tasks, timing, duration, and milestones. | Microsoft | Atlassian project lifecycle | Verified established practice |
| Burn-up charts separate completed work from total evolving scope. | Atlassian | Miro | Verified established practice |
| DSM represents relationships among system or project elements in a matrix. | MIT Sloan | MIT-hosted DSM paper | Verified established practice |
| Critical Chain incorporates resource constraints and pooled buffers. | PMI | Asana | Verified established practice |
| Delegated tolerances can allow minor change while escalating forecast exceptions. | PRINCE2 | PRINCE2 Wiki | Verified methodology principle |
| Human–AI orchestration can decompose work, allocate it among humans and AI, and adapt workflows. | Masters et al. | OpenAI multi-agent guide | Verified active research and implementation direction |
| Multi-agent scaling can itself produce coordination overhead. | Multi-agent orchestration survey | LLM multi-agent collaboration survey | Verified research concern |
| No established method uses the exact Solynth combination. | Preliminary search only | No exact match found among reviewed methods | Unverified possible novelty; further review required |
| Term | Working definition in the Solynth framework |
|---|---|
| Actor | A human or artificial-intelligence entity assigned responsibility for work. |
| AI actor | An artificial-intelligence worker executing a bounded task under permissions, controls, and review. |
| AI coordinator | A human practitioner who decomposes, assigns, supervises, validates, and integrates work performed by AI actors. |
| AI project-operating system | The connected planning, execution, evidence, testing, governance, and visualization environment proposed by Solynth. |
| Amplification factor, g(t) | A variable describing the strength of useful intelligence amplification during an iteration; it is constrained by evidence, risk, uncertainty, reversibility, and validation. |
| API | Application Programming Interface; a documented interface through which software capabilities and data can be invoked or exchanged. |
| Atomic task | The smallest independently tracked unit of work appropriate to the model. |
| Baseline | The approved initial reference for scope, schedule, cost, or another controlled dimension. |
| Brooks’s Law | The qualified observation that adding human labor to a late software project can make it later because of onboarding, communication, and task indivisibility. |
| Burn-up chart | A chart comparing cumulative completed work with total evolving scope. |
| CI — Controlled Intelligence | Governance that bounds and directs intelligence amplification through permissions, evidence, testing, risk controls, reversibility, and verification. |
| Closed-loop project operation | A workflow in which execution updates plans, issues, evidence, tests, health, interfaces, and visualization rather than leaving them disconnected. |
| Codebase connection | Governed AI access to repositories, histories, branches, changes, and associated development evidence. |
| Consolidated plan | A connected representation of objectives, features, benefits, capabilities, work, evidence, ownership, status, and decisions. |
| Contingency | Explicit reserve held against uncertainty and consumed only through defined rules or authorization. |
| Coordinated Intelligence | The arrangement of connected human and AI actors working through common plans, interfaces, context, and evidence. |
| Critical Chain | A scheduling method that considers precedence and resource constraints and protects delivery with pooled buffers. |
| Critical Path | The longest dependency path that determines the earliest possible completion of a project under a given schedule model. |
| Delegated authority | Permission for a role or team to approve changes within agreed limits without escalating every decision. |
| Dependency | A logical, technical, resource, or information relationship in which one element affects another. |
| Design Structure Matrix (DSM) | A square matrix showing relationships among project or system elements. |
| Evidence | Verifiable material supporting a status, decision, test result, claim, or completion assertion. |
| Gantt chart | A time-oriented bar chart of tasks, durations, overlaps, dates, and milestones. |
| Go/no-go | A controlled decision point determining whether the project or release proceeds. |
| Governed scope evolution | Reviewed, authorized, measured, and incorporated change to project scope. |
| Health file | A structured operational record of the condition of a component, service, integration, database, deployment, or platform. |
| Human/manual task | Work performed primarily through human action rather than delegated AI execution. |
| I³ | A metaphor for amplified or “cubed” intelligence arising from structured NI–AI collaboration; not a literal mathematical law. |
| IASER | Intelligence Amplification by Stimulated Emission of Reasoning; the iterative feedback metaphor in which NI stimulates AI and AI output stimulates improved NI. |
| Integrated test harness | A manual and automated facility that exercises component capabilities, records evidence, and supports repeatable comparison. |
| MCP | Model Context Protocol; an open standard connecting AI applications to external data, tools, and workflows. |
| Metadata | Structured descriptive information about project elements, relationships, ownership, state, provenance, and evidence. |
| NI — Natural Intelligence | Human judgment, experience, imagination, intention, responsibility, values, and contextual understanding. |
| Orange concurrency | The number of human and AI work items simultaneously in progress in the Solynth Web. |
| PERT | Program Evaluation and Review Technique; a network-based method for representing and estimating project activities. |
| Project participant | A human stakeholder, tester, manager, sponsor, reviewer, specialist, customer, or contributor who does not necessarily orchestrate AI. |
| RAG | Retrieval-Augmented Generation; generation grounded with retrieved external information. It is a supporting capability, not the whole Solynth model. |
| REST API | An HTTP-oriented API following resource and method conventions for reading or changing system state. |
| Scope creep | Uncontrolled or insufficiently governed expansion of scope; formally authorized expansion is better described as governed scope change. |
| Shared Intelligence (SI) | The emergent work product and coordination space created when AI and NI operate interdependently. |
| Solynth Network | The evolving ecosystem of projects, systems, people, AI actors, partners, customers, content, services, and commercial activity operating under the Solynth framework. |
| Solynth Web | The animated radial project-lifecycle visualization and proposed operational model described in this paper. |
| Spoke | A project dimension, domain, system, workstream, or measurable division represented radially in the web. |
| Stakeholder change control | The process for assessing, approving, rejecting, recording, and monitoring changes outside delegated tolerances. |
| Strawman simulation | An intentionally provisional implementation used to expose, discuss, and refine assumptions before validation. |
| Subtask | A visible refinement of a main task into smaller executable and trackable work. |
| Telemetry | Time-stamped operational data describing what the project and its actors actually did. |
| Tolerance | An agreed range within which delegated management may operate without escalation. |
| Traceability | The ability to connect requirements, decisions, tasks, code, issues, evidence, tests, releases, and outcomes. |
| Work in progress (WIP) | Work that has started but has not yet met its completion criteria. |
The Solynth Web belongs to a recognizable family of project visualizations, but it is not simply another Gantt chart drawn in a circle or another radar chart with project labels. Its core idea is a project that visibly reconstructs itself as knowledge, work, actors, and authorized scope change. Its deeper proposition is that artificial intelligence changes the resource problem: productive execution capacity may become more elastic than the human coordination surface, provided that orchestration, governance, testing, and evidence are built into the system.
The concept is strongest when treated as an integrating view backed by a rigorous data model. Its next test is not whether the animation looks persuasive. It is whether the model can ingest real Solynth project data, replay what actually happened, expose decisions and contingencies honestly, and improve prediction or governance compared with established views. If it can do that, the Solynth Web would be more than an infographic. It would become an operational instrument for coordinated intelligence.
Copyright © Robert Harvey Curtis (rhc)