Repository navigation
Advanced Reviews
Full ZASS can challenge an idea through different lenses.
These are optional tools, not mandatory ceremony.
Use only the lens that can change the decision or expose a meaningful risk.
Clarify components, responsibilities, flows, quality attributes and trade-offs.
Ask whether a future maintainer can understand, repair, upgrade and recover the system.
Check monitoring, alerts, handover, backup, recovery, capacity and human availability.
Ask what changes if users, data, commands or integrations grow by 10×–100×.
Assume internet, an AI provider or an integration disappears. Define minimum function, queue, retry and recovery behavior.
Turn vague claims into problems, questions, methods, measures and evidence.
Check data provenance, quality, mutability and how claims can be audited.
Replace a long debate with the smallest useful test of a critical assumption.
Break assumptions down to basics and rebuild from what is truly required.
Look for feedback loops, delays, side effects and interactions between stakeholders.
Search for edge cases, malformed input, network interruption and wrong action sequences.
Identify assets, attackers, attack paths, impact and defensive controls.
Look for manipulation, duplicate claims, fraud or exploitation.
Output must remain defensive: risks, detection, evidence and controls — not bypass instructions.
Challenge assumptions from an opposing perspective while returning defensive findings.
Assume the project failed later. Work backward to plausible causes and early mitigations.
Follow the user journey and find confusion, unnecessary steps, unsafe decisions and waiting points.
Evaluate time, cognitive load, skills, documentation and recovery burden for one maintainer.
Consider confidence, calm, enjoyment, frustration and meaning.
Ask who has the problem, what alternatives exist and why they would choose this solution.
Identify who might be harmed, excluded or unfairly burdened.
Check ability, language, device, connectivity and literacy differences.
Minimize collected data and clarify purpose, access, retention and user control.
Check relevant obligations before expensive design decisions become entrenched.
Map who benefits, who carries work/risk and where incentives conflict.
Temporarily remove familiar constraints to surface unexpected possibilities, then bring real constraints back.
Borrow patterns from other domains such as factories, hospitals, banking, games or agriculture.
Explore several plausible futures and test whether current decisions remain useful.
A review should normally return only useful deltas:
- findings;
- contradictions;
- risks;
- questions;
- candidate experiments;
- candidate decisions.
A review methodology has no authority to change LOCKED decisions by itself.