I keep judgment with the product owner and make execution traceable.
AI can increase the amount of software a small team can produce. My responsibility is to decide what deserves to be built, define what done means, and require evidence before work advances. I use named responsibilities and explicit gates so direction, execution, review, verification, and release remain visible.
Where I hold judgment
In my own products, I work as the Operator. I hold product direction, priority, authorization, and conflict resolution. I authorize the release shape, including scope, schedule, and any holds. Within that shape, the Lead performs routine release execution.
In my work with SKYL developers, I translate executive priorities and ambiguous business needs into ordered epics, stories, acceptance criteria, and definitions of done that engineering can execute. I remain accountable for the product decisions while developers perform the implementation. This describes my own working practice, not an organization-wide adoption of CH(Ai)SE or LEAD by SKYL.
How the work moves
- Direction. The Operator establishes product direction, priority, and the authorized release shape.
- Specification. The Lead turns that direction into project architecture and executable cards. Each card identifies its scope, acceptance criteria, evidence requirements, and definition of done before it becomes available for execution.
- Dispatch and execution. The Board dispatches ready work. Devs execute one card at a time within the declared file scope and return evidence with the completed work.
- Vetting and verification. The Board vets pull requests and merges accepted work to staging. Walker then exercises the merged behavior through its runtime path and records a verdict. The entity that merges the work is separated from the entity that verifies it.
- Review and release. Sprint findings receive documented dispositions. The Lead identifies release-ready work, performs routine releases within the Operator's authorized shape, and records the release outcome.
This is the full flow on my largest project. Smaller projects use less of it. This site, for example, has no staging environment, no sprints, and no Walker: the Board checks each change on production before closing it.
Seven entities, one chain of responsibility
LEAD assigns seven entities across portfolio and project scopes. Each holds a defined responsibility and boundary. A project's complexity determines how many of them it needs.
- Operator: the human source of direction, priority, authorization, and conflict resolution.
- Chaise: the portfolio methodology and governance owner. It authors cross-project standards under quoted Operator authorization.
- Counsel: the read-only portfolio reviewer. It researches, checks lineage, and returns findings without deciding, authoring, or executing.
- Lead: the project architect. It drafts and grooms cards, owns the definition of done contract, runs sprint ceremonies, and performs routine releases within the authorized release shape.
- Board: the project throughput owner. It dispatches work, vets pull requests, merges accepted work to staging, advances workflow state, and hands merged work to Walker.
- Walker: the runtime verifier. Tier 3, optional at Tier 2 with staging. It exercises merged work on staging and records the result without merging, dispatching, or setting the work to done.
- Devs: the bounded executors. They work one card at a time within declared file scope, using Standard mode when bounded judgment is required or Literal mode when the contract is frozen and ambiguity must stop execution.
The system beneath the work
CH(Ai)SE, the Collaborative Human-AI Standards Environment, defines the methodology: where judgment belongs, what evidence supports a decision, and how human authority and AI execution work together.
LEAD, Lineage-Enforced Agentic Delivery, defines the seven entities, their authorities, their boundaries, and the handoffs between them.
PULSED, Project Unified Lifecycle Staging Execution & Documentation, defines the project lifecycle from opening through repeating sprint cycles to project close.
FLIP (Feedback, Learning, Integration, Process) gives findings a deliberate review path. Every finding receives a disposition. A finding may produce project work, remain under observation, strengthen an existing rule, become a shared rule, or close with another recorded outcome. Only some dispositions change canon.
Read "One-off or pattern: where a lesson belongs"
Internal Logic is the domain knowledge that shapes a correct product decision before implementation begins. Capturing it in specifications and project canon gives executors relevant constraints at the point of work instead of waiting for those constraints to surface during review.
Explore the CH(Ai)SE methodology
What I have observed
I document the sprint observations from applying this model in the Arc Katalyst case study. They are presented as observations from my own work, with their limits stated, not as a promise that the same process will produce the same result elsewhere.
Intellectual Property Notice: The CH(Ai)SE methodology, LEAD entity model, PULSED lifecycle framework, and FLIP feedback-learning-integration process are intellectual property of Perry Wolfe. These systems are not authorized to be copied, used, or distributed without explicit permission.