Groundcall
[Established]
Operational. A single command — Groundcall, or a recognized synonym (unpack, elaborate, full version, from scratch, no assumptions, step by step) — that signals the model to drop accumulated shorthand and expand the current context into fully explicit, junior-accessible prose with no assumed knowledge. At the token level it surfaces the full depth of the compression that has been operating implicitly, so the practitioner can confirm the shared ground is still intact and intended.
When it’s needed. Rarely, in a well-established session — a strong preseed functions as a permanent zero-point reference the session never fully departs from. When Groundcall is needed, it usually signals that compression has accumulated faster than shared ground has been maintained: the model has been extending shorthand in unverified directions. Groundcall makes the drift visible before it compounds.
Requirement. Groundcall depends on a stable lattice. Without a preseed, Groundcall synonyms produce only generic elaboration — there is no established compression to surface. (This is also why terse aphoristic guardrails fail: a bare slogan has no depth beneath it for Groundcall to unpack.)
Maximum Forward Speed
[Established as a discipline]
Operational. The operating posture once shared ground is confirmed: present structure, expect structure in response; reset to explicit ground truth with Groundcall when needed; honor focus and completion so resonance compounds. Paired with the Task Flow single-active-task discipline on the human side, it is the metronome that keeps the session moving without manufacturing coordination overhead. The proactive momentum is human, maintained by a practitioner who has internalized the method — not an autonomous behavior of the model.
Artifact Trigger Protocol
[Established — instructable behavior]
Operational. The session remains in shaping / advisory / refinement mode until an explicit trigger (“build the artifact,” “output the HTML,” “deliver the working version”). On trigger, it produces a single-file, zero-friction, production-quality artifact. This makes artifact production an explicit, declared behavior rather than an emergent surprise, and lets shaping and building stay cleanly separated.
Task Flow — the operating layer
[Established as a practice; “zero coordination tax / JIRA native / half the headcount” bounded by the discipline’s own article]
Operational. Task Flow is a standalone, AI-independent activity-management discipline — it runs with or without any model (JIRA, a whiteboard, paper), and the symbiote relates to it only as reference material (see below). Its precise scope — stated most carefully in the discipline’s own Task Flow article — is activity-management optimization: the layer where hands touch work (what needs doing, who is doing it, where it stands, and how that status becomes visible), not the project as a whole. Three states hold all work — IN PROGRESS / TO-DO / DONE — every task in exactly one, the list public and shared. The iron rule is the Single Active Task Rule: one IN PROGRESS at a time, no primary-plus-secondary, no exceptions. Status propagates by ambient awareness — public visibility plus a signal layer (in its native JIRA home, an RSS feed delivering transition “screen-pops” to the Orchestrator) — so situational awareness is structural rather than manufactured in meetings.
The pipeline paradigm (the genuinely original frame). Task Flow imports the CRM enterprise opportunity pipeline directly into engineering work: the Story is the Opportunity, the Acceptance Criteria the declared closed-won condition, the Tasks beneath the Story the pipeline stages, and the Orchestrator the pipeline manager — scanning the assignment pool, feeding the next task to the next available owner, coordinating through the pipeline rather than about it in ceremonies. This is the strongest idea in the operating layer: situational awareness as a property of the architecture, not of a scheduled event designed to generate it.
Why the single-active-task rule works (and where it’s borrowed from). Concentrating one task to completion removes context-switching cost, partial-attention tax, and the coordination surface that parallel work-in-progress creates. Held honestly: this is well-grounded but not novel — it is the WIP-limit principle of Lean/Kanban, stated as an absolute. The absolute form is its strength — it forbids the multitasking culture’s drift and converts blocked-ness into re-pooling rather than waiting; the cross-cutting-dependency case it raises is handled structurally (see below).
Bounded claims — by the discipline’s own article. The earlier taxonomy register runs hot: “Zero Coordination Taxes,” “15 breakthrough disruptors,” “existential threat to JIRA, PMOs, Agile, enterprise licensing,” “velocity and quality at half the headcount.” The Task Flow article itself supplies the correction, and the taxonomy follows the article — it “does not abolish the standup or dismantle the status meeting… does not replace Scrum, retire Agile, or file JIRA’s obituary,” and “status meetings and standups serve genuine project functions and they are not going anywhere.” So:
- “Zero coordination tax” → removes the manufactured activity-reporting overhead (status reports written to generate visibility the live, public task list already provides), not all coordination. Real and valuable; not “zero.”
- “JIRA / Agile / PMOs” → a mental model that runs inside those tools and frameworks (JIRA is its native home), making them perform nearer their ceiling — not a replacement for them.
- “Half the headcount / velocity and quality simultaneously” → an unbenchmarked productivity claim; the defensible version is that removing the reporting layer reclaims real time, magnitude unproven.
Cross-cutting dependencies — resolved structurally. The narrowed question closes via the same CRM import that gives Task Flow its pipeline. An Activity record is not owned by a single project; it is a shared entity that multiple Stories can reference. A dependency spanning projects is therefore not a fragile link between two siloed items — it is one record appearing in every pipeline that depends on it. When it transitions to DONE, every referencing project sees the change through the shared reference at once, with no cross-project visibility gap to bridge: the Orchestrator sees cross-cutting dependencies in aggregate because the shared record’s reference set is the aggregate. (This is native to the CRM data model; porting it faithfully requires a tool that supports multiply-referenceable work items — in JIRA, via issue links or a shared issue.) What remains is not a structural gap but an ordinary scheduling fact: if many pipelines genuinely wait on one unfinished upstream record, that is pool pressure — now fully visible as the single record many pipelines reference, hence actionable by the Orchestrator rather than hidden. Whether it arises at all is empirical; the provenance projects did not exhibit it.
Relationship to the symbiote (reference only, not a dependency). Task Flow has no AI dependencies. The symbiote’s role is purely reference: because Task Flow is in no model’s training, a preamp supplies the compressed methodology, and from that compression a model can guide practitioners in it — track state, surface the next Task, answer in-method — even though it never saw Task Flow during training. The dependency runs one way only: the symbiote draws on Task Flow as reference; Task Flow draws on nothing.
This makes Task Flow a clean worked example of The Empty Set’s productive side. The methodology is novel — not latent in any model — yet a preamp naming it binds and the guidance is real, because the novelty is in the arrangement while the primitives it keys into (a task, a pipeline, a CRM opportunity, coordination, prose-as-instruction) are latent structure every capable model already carries. A document can name what is not in the model; what it cannot do is conjure substrate. Task Flow needs none conjured — its parts are all already there to key into, which is exactly why the compression takes.
Metaphor (grounded + bounded). “The best tool is the one that disappears when you use it.” Grounded: when the activity layer is clean, the overhead built to compensate for its absence stops being necessary — the process recedes. Bounded: “disappears” describes reduced reporting friction, not the disappearance of coordination, meetings, or the project’s real complexity, all of which remain.
Note. Task Flow has its own dedicated reference (the Task Flow—TAXONOMY). This entry represents the operating layer at the altitude the Symbiote AI taxonomy needs; the full state model, vocabulary, Orchestrator playbook live there and should inherit the same calibration applied here.