Process Administration & Management: Kernel Objects

Taxonomy, Slicing Standards, Cardinality, and the Shift-Left Directive

1. Executive Summary: The Shift-Left Mandate

In transient, chat-based agent harnesses, agents write massive, monolithic changes across entire codebases with superficial PR summaries. In the ZQK Knowledge Kernel, reality is governed by verified, immutable graph objects.

Waiting for git commit check-valves or zqk-vet to catch errors is a late-stage fail-safe. Process Administration must Shift Left: agents and human operators must understand the exact purpose, trigger, boundaries, and cardinality of kernel objects before minting objects or writing code.

2. Kernel Object Taxonomy (What / When / Why / How Many)

Object Kind	What (Definition)	When (Trigger)	Why (Rationale)	How Many (Cardinality Ratio)
`goal`	Strategic end-state condition.	Project kickoff or major strategic direction shift.	Anchors strategic North Star; defines what success looks like independent of sprints.	1 per product tier / mission
`milestone`	Significant stakeholder boundary event.	Key external release or major capability delivery.	Demonstrates real-world value delivered to executive and external stakeholders.	1 to 3 per Goal
`epic`	Thematic container grouping multiple plans.	When an initiative spans multiple time cycles or sprints.	Keeps related execution cycles organized under one identifiable umbrella.	1 to 3 per Goal
`priority_plan`	1-cycle time-bounded execution block.	Start of each execution cycle / sprint.	Reigns in scope commitments to ensure work gets completed, not parked.	2 to 5 per Epic (1 cycle of work)
`requirement` (REQ)	Whole feature functional contract (`MUST`, `MUST NOT`).	Outlined during design to bound problem statement and operational scope.	Formalizes functional truth and boundary conditions independently of code.	3 to 5 per Goal (1 to 3 per Epic)
`test_case` (TST)	Unified test runner proving a requirement.	TDD upfront test harness created before or alongside code.	Cryptographically proves all linked criteria in a single logical test command.	1:1 with Requirement
`criteria` (CRIT)	Mathematical measurement or falsifiable condition.	Created alongside the requirement before coding begins.	Eliminates hand-waving; drives automatic shockwave state graduation.	Minimum 3 per REQ (The Three-Fold Proof)
`backlog_item` (BLI)	Atomic unit of effort & commit evidence.	Sliced before coding starts for a single cohesive subsystem.	Enables swarm parallelism, limits blast radius, provides deterministic AST rollback.	2 to 5 per Plan (Each satisfies 1–3 CRIT)

3. The 5-Layer Relational Cascade

                  ┌───────────────────────────────┐
                  │          GOAL                 │
                  │   Strategic End-State         │
                  └───────────────┬───────────────┘
                                  │ 1 : 3-5
                                  ▼
                  ┌───────────────────────────────┐
                  │       REQUIREMENT (REQ)       │◄─────────────────────────────┐
                  │    Whole Feature Contract     │                              │
                  └───────────────┬───────────────┘                              │
                                  │ 1 : 3+                                       │
                                  ▼                                              │ Verifies All Criteria
                  ┌───────────────────────────────┐                              │ for the Requirement
                  │        CRITERIA (CRIT)        │                              │ (1 per Requirement)
                  │  Static · Operational · Neg   │                              │
                  └───────┬───────────────┬───────┘                              │
         Satisfies 1-3    │               │                                      │
         Criteria / Effort│               │ Evaluated by Unified Runner          │
                          ▼               ▼                                      │
           ┌──────────────────────┐   ┌──────────────────────────────────────────┴────┐
           │  BACKLOG_ITEM (BLI)  │   │                TEST_CASE (TST)                │
           │  Unit(s) of Work     │   │ Unified Test Runner / Logical Verification    │
           │  (2-5 per Plan)      │   │ Group proving the entire Requirement          │
           └──────────────────────┘   └───────────────────────────────────────────────┘

Critical Linkage Rules

Goals DO NOT have criteria_refs: Goals are high-level strategic compasses. They decompose into Requirements via requirement_refs. Only Requirements own criteria_refs.
Requirements own criteria_refs: Every requirement MUST define at least 3 criteria satisfying the Three-Fold Proof.
Test Cases are 1:1 with Requirements: A test case wraps all criteria linked to a requirement. Running zqk test run <tst_id> evaluates the complete feature contract in one unified pass.
Backlog Items satisfy 1–3 Criteria: A Backlog Item is an atomic slice of implementation effort. It links to a time-bounded priority_plan and satisfies 1 to 3 specific criteria.

4. The Gantt Matrix Topology

In ZQK Studio and execution planning, the graph renders as an audited two-dimensional execution grid:

                            TIME-BOUNDED EXECUTION CYCLES (Priority Plans)
                         Cycle 1 (Sprint A)        Cycle 2 (Sprint B)       Cycle 3 (Sprint C)
                        ┌─────────────────────┐   ┌─────────────────────┐   ┌─────────────────────┐
                        │ PRI-PLAN-001        │   │ PRI-PLAN-002        │   │ PRI-PLAN-003        │
                        └─────────────────────┘   └─────────────────────┘   └─────────────────────┘
┌─────────────────────┐ ┌─────────────────────┐
│ WORKSTREAM 1        │ │ [BLI-001] [BLI-002] │ ──► Milestone 1: Core Engine Alpha ★
│ (Lanes / Rows)      │ └─────────────────────┘
├─────────────────────┤                           ┌─────────────────────┐
│ WORKSTREAM 2        │                           │ [BLI-003] [BLI-004] │
│ (e.g. Studio UI)    │                           └─────────────────────┘
├─────────────────────┤                                                     ┌─────────────────────┐
│ WORKSTREAM 3        │                                                     │ [BLI-005] [BLI-006] │ ──► Milestone 2: Public Preview ★
│ (e.g. DevRel)       │                                                     └─────────────────────┘
└─────────────────────┘

Workstreams (Rows / Swimlanes): Ongoing functional domains (e.g., Core Engine, Studio UI, Developer Relations).
Epics (Grouping Banners): Unifying thematic containers that span across multiple cycles.
Priority Plans (Columns / Blocks): Discrete, 1-cycle execution windows that lock scope.
Backlog Items (Intersections): The units of effort executed within that cycle and lane.
Milestones (Flags / Anchors): Significant stakeholder boundary events crossing delivered reality.

5. Epic Shockwaves & Permissive Scope Invariant

Child ➔ Parent Shockwave Progression:
When the first linked priority_plan transitions to in_progress, the parent epic automatically shockwaves from planned ➔ in_progress.
When all linked priority plans reach complete, the parent epic automatically shockwaves ➔ completed.
Permissive Scope Invariant:
Priority Plans are strictly scope-locked upon entering in_progress to guarantee cycle completion.
Epics are permissive by default. Operators and agents can freely attach new priority_plan objects to an in-progress epic as the initiative evolves across cycles.
An epic can be explicitly locked by setting execution_locked: true when no further plans may be added.

6. Cardinal Anti-Patterns vs. Correct Practice

Anti-Pattern 1: The "BLI Hijacking" Anti-Pattern (Scope Stacking)

Violation: The user asks for a new Web UI or macro feature, and the agent tacks it onto an existing or completed BLI (e.g. adding a prompt studio to BLI-REPLY-ENGINE-001).
Correct Practice: Never mutate or stack scope onto an in-flight or completed BLI. Mint a new BLI (zqk new bli "Prompt Studio Web UI" --plan PRI-xxx).

Anti-Pattern 2: The Degenerate 1:1:1:1 Pipeline

Violation: 1 Goal ➔ 1 Plan ➔ 1 BLI ➔ 1 REQ ➔ 1 CRIT. The BLI becomes a massive monolithic PR bundling database, engine, kill switch, and UI into one commit.
Correct Practice: Decompose the plan into 2 to 5 orthogonal BLIs, each satisfying 1–3 criteria.

Anti-Pattern 3: The Three-Fold Proof Omission

Violation: Defining a single criterion: CRIT-001: Works as expected.
Correct Practice: Every requirement must have at least: 1. Static Invariant Floor: Schema validated, types correct, lint zero. 2. Operational Dynamic Proof: Programmatic test suite exits 0 with asserted output. 3. Negative / Adversarial Boundary: Invalid inputs, timeouts, or unauthorized calls fail closed safely.