Qv Qip Review

QIP Proposal Review

Review a QIP without substituting for its human approvers. Use qv-qip-create for first drafts and qv-qip-triage to decide whether a QIP is needed.

Ground the review

1. Read ../qv-qip-create/references/qip-template.md.
2. Read docs/architecture/PRINCIPLES.md.
3. When the proposal changes runtime, package, plugin, registry, storage, transport, security, public API, release, or deployment boundaries, check its system fit against docs/architecture/ARCHITECTURE.md and the relevant current repository sources.

Do not infer approval, commitments, current behavior, or implementation feasibility without evidence. Treat principle conflicts as review findings, not automatic rejection, unless the proposal hides or misrepresents the conflict.

Review criteria

Decision readiness

• Problem explains what matters and why a decision is needed now.
• Solution recommends one direction and states the exact approval ask.
• Architectural responsibilities, boundaries, interactions, and rationale are concrete enough to evaluate.
• Obvious alternatives are addressed briefly, with supporting research summarized in the Appendix when needed.
• Consequences state positive impact and the trade-offs reviewers must accept.
• Decision-relevant trust-boundary, compatibility, migration, and release effects are explicit.
• Likely scope misunderstandings are excluded explicitly, and the approvers table is preserved.

An unclear or absent recommended direction or approval ask is a blocker. For another gap, first state how its answer could materially change the recommendation or why approval without it would be irresponsible. Explicitly deferred implementation detail is acceptable when the architectural direction, boundaries, responsibilities, and accepted trade-offs remain clear; require production-level detail only when the decision or its feasibility and risk claims depend on it. Do not use length or a preference for greater specificity as a proxy for readiness.

Decision-brief quality

• Use 600-900 words as the target and 1,200 words as a soft ceiling for the core proposal, excluding the approvers table and Appendix.
• Length above the ceiling is a suggested edit, not a blocker by itself.
• Flag specific passages when repetition or implementation detail buries the problem, recommended direction, architectural boundary, or accepted trade-offs.
• Recommend removing file lists and moving useful APIs, protocols, execution steps, test plans, rollout detail, failure-mode analysis, and large comparisons to the Appendix unless they directly affect approval.
• Check that the Appendix is relevant and organized, research has been synthesized rather than reproduced, external artifacts explain their relevance, principle references explain a concrete fit or conflict, and images are linked rather than embedded as base64 data.