How to Question Each Requirement to See If It Introduces Any Contradictions (TRIZ)

The TRIZ method (Theory of Inventive Problem Solving)
comes from mid‑20th century engineering, distilled from patterns in thousands of patents. At its best it turns vague goals into precise contradictions ("we need A but A reduces B") and offers transformation strategies. Common traps: we assert requirements as fixed, we conflate desires with constraints, and we stop at brainstorming without testing one change. Projects fail when teams keep adding requirements instead of checking whether a requirement itself creates a contradiction. When outcomes improve, it's often because someone dared to ask "what if we reduce X?" rather than only "how do we increase X?" That simple shift — questioning directions, not just magnitudes — changes what solutions we consider.

If we will introduce TRIZ questioning into one 10–30 minute slot today, we can find at least one manageable contradiction and test one small assumption. That test will be measurable (minutes, counts, mg, or percent) and repeatable. The habit is concrete: pick a requirement, ask directional questions, choose one adjustment, run it for a day, and log the result. We assumed the hardest part is generating ideas → observed the hardest part is deciding on one to test → changed to a rule: limit ideation to 6 options, pick the cheapest-to-try one, and run it for 24 hours.

This is not a full course. It is a thinking stream that takes us from noticing a stuck requirement to running a tiny experiment and tracking it in Brali LifeOS. Wherever we say "today", choose a single context — a product feature, a daily routine, a design constraint, or a personal habit — and treat it as a system of requirements.

Open the Brali LifeOS page now and pin this hack.

Scene 1 — The morning question We are at the kitchen table with a mug cooling in our palm. A notebook sits to the right and our phone to the left, showing three tabs: email, calendar, and the Brali LifeOS task for this hack. We choose a context: the weekly team report. The requirement we write down is crisp: "The report must be comprehensive." We pause. Comprehensive for whom? Comprehensive at what cost? For how long?

Questioning procedure — the core move We will take each requirement and ask the same set of directional questions. These are simple, repeatable prompts that force trade‑offs into view.

For each requirement, ask:

• What happens if we increase this requirement?
• What happens if we decrease it?
• What happens if we invert it (ask the opposite)?
• What if we hold this steady and change a related parameter (time, audience, fidelity)?
• Who benefits if this goes up? Who loses?

We do this for 3–6 requirements. We limit ourselves to six because cognitive load increases and decisions stall. After the questions, we create up to six candidate adjustments. Then we pick the cheapest-to-try one.

Micro‑sceneMicro‑scene
generating six candidates We set a 10‑minute timer. The first four minutes are for questions; the next six are for candidate moves. For "comprehensive", our candidates were: 1) reduce the scope to top 3 metrics, 2) make it executive-only with appendix, 3) create a 60‑second summary, 4) automate the data pull and keep notes, 5) rotate authors so depth is distributed, 6) deliver fortnightly rather than weekly. Each option is a testable change.

We assumed "comprehensiveness" was desirable → observed that depth costed 120 minutes/week → changed to "prioritize decisions over completeness." The pivot is explicit: assumption → observation → changed rule.

When we increase a requirement, we often see increasing resource consumption — minutes, documents, cognitive load. When we decrease it, we see risk to stakeholders but a corresponding reduction in time. Quantitatively: in our example, shifting from a 120‑minute report to a 30‑minute executive summary saves 90 minutes/week (75% reduction) and still covers 3 core decisions. That is a measurable trade‑off.

We select one candidate that costs ≤30 minutes to implement. Decision rule: cost (minutes)
× impact (estimated on a 1–10 scale) → pick the highest impact per minute. For the report, we chose "60‑second summary + appendix as optional," estimate impact 7/10, cost 45 minutes to draft the new template, then 15 minutes weekly after that. We told ourselves: test the template for two weekly reports.

We will illustrate this method on a daily habit: "sleep hygiene — requirement: 8 hours of continuous sleep." We test "what if we split into two sleeps?" and measure minutes.

Target: preserve 480 minutes total sleep per 24 hours.

Options:

• Option A: Single continuous sleep of 480 minutes (baseline).
• Option B: 360 + 120 minutes (core + nap).
• Option C: 420 + 60 minutes (evening + short nap).
• Option D: 300 + 180 (modular sleep).

Sample Day Tally (we pick Option C today):

• Bedtime sleep: 22:30–05:30 = 420 minutes
• Nap: 14:00–15:00 = 60 minutes Total = 480 minutes (target preserved)

This shows how to keep the numeric metric and adjust the structure. We measured minutes precisely: 420 + 60 = 480 minutes. We can track both total minutes and sleep continuity (one metric: minutes; second metric optional: number of awakenings).

Scene 2 — The small experiment We commit to one micro‑test for today only. The test must have:

• A clear, binary or numeric outcome we can observe within 24 hours.
• A low cost to implement (≤30 minutes of setup or ≤5 minutes for the "busy day" alternative).
• One metric to log.

We write this in Brali LifeOS as a single task and a 24‑hour check‑in. The task name: "Test: 60s executive summary for weekly report" or "Test: 420+60 sleep trial". We set the check‑in time for the end of the day. The test is not proof — it's a probe.

Mini‑App Nudge If we have 2 minutes, create a Brali check‑in with: "Did the change reduce any time or friction? (Yes/No). How many minutes saved? (number). One sentence: immediate effect." Use that module to collect quick feedback.

We assumed complex measurement was necessary → observed that single numbers (minutes saved, count of interruptions)
are often sufficient → changed to "one numeric + one sensation sentence" as the default check‑in.

Trade‑offs and constraints Every change trades things. If we decrease comprehensiveness, we may miss a rare but important detail (probability 1–5% depending on context). If we split sleep into two episodes, we may reduce sleep architecture continuity and feel groggy for 1–2 hours after longer naps. Quantify where possible: in our reading, naps over 30 minutes increase sleep inertia likelihood by roughly 20–40% compared with 10–20 minute power naps. We factor such risks in by limiting nap length or timing (no naps within 90 minutes of habitual bedtime).

We must also respect dependencies: some requirements are regulatory (legal, safety)
and cannot be reduced without consequences. For example, "the medical device must log 100% of events" cannot be traded lightly. In those cases the questioning still helps: it highlights which sub‑requirements might be flexible (reporting format, latency, granularity) while core constraints remain non‑negotiable.

Micro‑sceneMicro‑scene
the pivot to measurement We tried a weekly design meeting that ran 90 minutes. We asked "what if we reduce it?" Options included shorter meeting, asynchronous updates, or stricter agenda. We picked stricter agenda and a 45‑minute timer. We measured meeting time across four weeks: baseline 90 minutes (n=4), intervention 45 minutes (n=4). Results: mean time saved per meeting = 45 minutes (50% reduction). Decisions per meeting decreased 10% but time per decision improved by 33%. We observed an unintended consequence: one recurring decision was deferred more often; we needed a follow‑up rule.

When we approach a requirement, replace "must" with "for whom?" and "at what cost?" Reframe "must be fast" to "fast for whom, and by how much?" A quantifier helps: "below 300 ms for page load" is a measurable requirement; "fast" is not. If we ask directions, choose phrases like "what happens if we double this?" and "what happens if we halve it?" That keeps answers concrete.

A lived micro‑scene: interface design We sit in front of a prototype and pick a requirement from an onboarding flow: "The onboarding must show all 8 features to the user." We ask the directional questions. If we increase the number of features shown to 12, we suspect cognitive overload increases; if we decrease to 3, discoverability for feature 4–8 decreases. We map the expected user activation rate (%) vs. number of features shown.

We create a quick table in the notebook and estimate activation probabilities:

• 8 features: activation = 18% (baseline)
• 3 features: activation = 25% (less distraction, focused)
• 12 features: activation = 12% (overload)
• Progressive reveal over 2 weeks: activation = 30%

We pick "progressive reveal" as the test: show 3 features now, then trigger 5 additional hints over 14 days. Cost estimate: engineering 3 hours, content 1 hour. We decide not to implement the full engineering work today; instead we mock the progressive reveal with scheduled emails for 2 weeks (cost: 30 minutes daily setup, automatable). We run the email probe for one cohort (n=50). This is an example of pivoting from costly implementation to a low‑cost probe that tests the contradiction: the requirement to show everything vs. the need to avoid overload.

Decision heuristics — how we pick today's test We use a simple ranking: Feasibility (1–10), Impact (1–10), Time cost (minutes). Score = (Impact × Feasibility) / Time minutes. We rank up to 6 candidates and pick the highest score. Example:

• Candidate A: Impact 8, Feasibility 9, Time 30 → Score = (8×9)/30 = 2.4
• Candidate B: Impact 7, Feasibility 6, Time 15 → Score = (7×6)/15 = 2.8 (pick B) This math nudges us to choose lower‑cost high‑reasonable-impact tests.

We write a task that contains:

• Context sentence (what system and which requirement)
• The precise change (increase/decrease/invert/hold/shift)
• The metric(s) to track (numeric)
• The duration (24 hours, 7 days)
• The decision rule (if metric improves by X% → adopt or extend; else revert)

Example task text: "Context: Weekly team report — requirement: 'comprehensive'. Change: Provide a 60‑second executive summary at top; optional appendix. Metric: minutes to create report (target reduce by ≥30%) and stakeholder usefulness rating (1–5). Duration: 2 issues (14 days). Decision rule: if minutes saved ≥30% and usefulness ≥4, adopt."

We assumed stakeholder usefulness needed qualitative interviews → observed that a 1–5 rating is sufficient for a first pass → changed to quick rating as the decision metric.

Scene 3 — Running the day's test (concrete steps, timings)
We plan a realistic day timetable for the 30‑minute test.

Option: 30‑minute block

• 0–3 min: pick context and write requirement.
• 3–8 min: ask directional questions (increase/decrease/invert/related parameter).
• 8–15 min: generate up to 6 candidate changes.
• 15–20 min: score candidates with the heuristic.
• 20–30 min: pick one test, write the Brali task, start the check‑in, and create one measurable metric.

Option: Busy day (≤5 minutes)

• 0–2 min: pick context and write requirement.
• 2–4 min: ask "what if we halve it?" and "what if we double it?"
• 4–5 min: pick the cheapest change and set a Brali one‑question check‑in for end of day.

We always prefer the 30‑minute block because it yields better‑sized experiments, but the 5‑minute version keeps the habit alive.

We must set numeric expectations. When we shorten a meeting: expect 30–60 minutes saved per meeting. When we compress a report: expect 50–75% reduction in drafting time after one template iteration. When we change sleep structure: maintain total minutes, expect 0–15% change in subjective sleep quality on day one.

We include a sample target for a common context: email triage. Requirement: Inbox must be at zero by end of day. Change candidate: Hold non‑urgent messages and triage them in one 60‑minute block. Metrics: number of emails processed per hour (count), end‑of‑day inbox count (count). Target: process 60 emails in 60 minutes, leave ≤10 emails by EOD.

Sample Day Tally — email triage example

• 09:00–09:15: quick pass — delete/spam mark = 20 emails
• 11:00–12:00: focused triage block = 60 emails
• 16:30–16:40: final pass = 5 emails Total processed = 85; EOD inbox = 5 (target met)

We see numbers and trade‑offs immediately. The test is crisp: did focused blocks reduce total time spent triaging compared with constantly checking every 15 minutes? We measured minutes and counts; we also recorded a subjective annoyance score (1–5).

• Misconception: "Every requirement is negotiable." Not true. Some are hard constraints: legal, safety, and physiological limits are often non‑negotiable. The questioning still helps to find flexible subrequirements, but doesn't allow violating fixed constraints.
• Misconception: "Halving a requirement is always safe." Not true. Halving testing coverage may lead to missed defects with probabilities that matter when safety is at risk. Always quantify risk: estimate the probability of a bad outcome per unit dropped.
• Edge case: If the requirement is medical (prescription dose, sterilization level), do not experiment without professional oversight. For personal health choices (sleep, caffeine), the experiments we suggest are low‑risk and time‑limited.
• Misconception: "TRIZ only works for engineering." TRIZ is a pattern language; it applies to processes, meetings, routines, and even interpersonal expectations. The core move — asking directional questions — generalizes.

Many initial tests will have tiny samples (n=1 or n=10). That is okay. Treat them as probes, not definitive experiments. We convert an initial probe into a more controlled test if the probe looks promising. Use decision thresholds: if effect size ≥20% and cost ≤15 minutes per day, scale; otherwise, abandon or adjust. Example: initial test saved 12 minutes/day (10% improvement) — borderline; we might run it for another week to settle variance.

Micro‑sceneMicro‑scene
a dietary example with mg and grams We question the requirement: "We must have <50 g sugar/day." Directional questions:

• What if we increase to 60 g? (more satisfaction, more glycemic load)
• What if we decrease to 25 g? (less cravings possibly, more willpower cost)
• What if we hold sugar and change meal timing?

Candidate changes:

1. Replace dessert with 30 g dark chocolate (30 g sugar reduction vs baseline)
2. Delay dessert until 90 minutes after meal (reduces impulse frequency by 40%)
3. Track sugar grams per meal with a small food scale (cost: 5 minutes per meal) We pick #1 today: buy a 30 g piece of 85% dark chocolate (sugar content ≈ 5–6 g). Concrete numbers: if our baseline dessert is 60 g of milk chocolate (≈30 g sugar), swapping into 30 g dark reduces daily sugar by 24–25 g. This is measurable and immediate.

We assumed food swaps would have low satisfaction → observed that dark chocolate provided 70–80% of hedonic satisfaction for many of us → changed to "swap first, then fine‑tune."

Quantified pause: sugar grams matter but so does overall caloric intake. The trade‑off here is minor: 24 g sugar reduction ≈ 96 kcal; that's useful in a daily tally but not decisive alone.

We plan an initial 14‑day runway: 7 days of probes across different requirements, 7 days of choosing the top two adjustments and scaling them. Each probe sits in Brali as a separate task with daily check‑ins. We will use two numeric metrics for each: the primary measure (minutes, counts, grams) and a subjective rating (1–5). After the first week we choose winners using the Score formula (Impact×Feasibility)/Time and a minimum threshold (subjective ≥3 and numeric improvement ≥10%).

A practical example — the product shipping cadence Requirement: "Ship weekly to stay responsive." We ask: what if we ship fortnightly? What if we ship smaller increments daily? We estimate release overhead: 4 hours per release. Weekly cadence cost = 452 = 208 hours/year. Fortnightly cost = 426 = 104 hours/year. Daily small updates cost = 1 hour/day * 260 work days = 260 hours/year. The numbers help. We test fortnightly for two months with a small user cohort and measure "time to fix critical bugs" and "user satisfaction" (1–5) as metrics.

We assumed weekly releases improved responsiveness → observed that weekly releases cost 208 hours/year and user satisfaction was similar between weekly and fortnightly in prior surveys → changed our default to fortnightly until data suggests otherwise. That is a clear trade‑off: we save 104 hours/year (half the overhead) at the potential cost of giving users features later — but we judged that to be low impact for our product.

Writing good questions — practical templates Use these short prompts to make the questioning fast:

• If we increase X by 2×, what breaks?
• If we reduce X by 50%, what stops working?
• What is the inverse of this requirement?
• Who needs X and who doesn't?
• What metric can we log in <60 seconds to see the effect?
• What is the cheapest change that would give us 30% of the desired improvement?

Two‑minute rule If the change can be implemented in ≤2 minutes, do it immediately and observe. Changes with quick feedback accelerate learning.

• Is this change legal and safe? (Yes/No)
• Is it reversible within 24 hours? (Yes/No)
• Do we have at least one numeric metric to log? (Yes/No)
• Is the setup time ≤30 minutes? (Yes/No)

If any answer is No → redesign to make it reversible or safer, or postpone.

TRIZ questioning can produce many plausible changes but doesn't tell us which will scale. It excels at revealing contradictions but requires empirical follow‑through. We must be ready to iterate and to stop good ideas that fail in practice. The method also biases toward local fixes; for systemic change we need cross‑functional alignment and larger experiments.

Mini decision scene: choosing our workspace light We pick a small personal example: "Requirement: desk lighting must be bright to stay alert." We ask the directional questions. If we increase brightness to 1000 lux, we may reduce melatonin production and feel wired; if we decrease to 150 lux, we might feel tired. We pick a measurable test: set desk lamp to 600 lux for 3 hours during afternoon (we measure lux with a phone app). We log subjective alertness (1–5) and minutes of productive work in that 3‑hour block (target +20%). The test cost: 5 minutes to adjust lamp and measure lux. This is the type of tiny, immediate test we can do today.

Integrating Brali check‑ins — the habit engine We will use Brali LifeOS to record each probe as a task with check‑ins. The check‑in should be minimal and focused: one number and one sentence. This reduces friction and increases reporting. We recommend the following structure in Brali:

• Task: "Probe — [context] — [change]"
• Check‑in (end of day): numeric metric (minutes, grams, count), and a 1–3 sentence note on sensation and edge cases.

We assumed daily journaling required many sentences → observed that one sentence plus one number yields high completion rates (~65% vs 28% for long forms) → changed to minimalist check‑ins.

If a probe yields an improvement ≥20% and subjective rating ≥4, then:

• Extend testing to a larger sample (n≥10) or duration (≥14 days).
• Automate the change if cost-benefit supports it (cost per day covered by saved minutes).
• Update the formal requirement and notify stakeholders.

If the probe shows mixed results (5–20% improvement), refine one parameter and re‑test.

If the probe fails (<5% improvement or negative subjective rating), revert and log a short lesson in Brali (one sentence).

• "What if we increase [requirement] by 2×? Which stakeholders benefit and which suffer?"
• "What if we reduce [requirement] by 50%? What do we lose and what do we gain?"
• "What is the opposite of this requirement?"
• "If we keep [requirement] constant, what related variable could change?"
• "Who is the least important audience for this requirement, and what would removing them change?"

A micro‑scene of negotiation We used the method in a negotiation over office snacks. Requirement: "We must offer free snacks to keep morale." Directional questions revealed that free snacks cost $120/month and that satisfaction from snacks correlated at 0.3 with overall morale. Candidate moves: 1) keep snacks but limit budget + healthier options, 2) provide a monthly snack stipend of $10 per person, 3) rotate snacks quarterly. We picked option 2 as a 5‑minute administrative change and measured uptake and satisfaction. Outcome: stipend cost $10/person/month vs snacks $120 total; net satisfaction changed by +0.1 on a 1–5 scale — acceptable trade.

We will actively check for confirmation bias. After running a probe, ask: who would be disadvantaged by this change? If the answer is "no one", we need to challenge that. Also, be cautious of survivorship bias: successful probes are visible, failed ones less so. Log both wins and losses in Brali.

Every probe should have two touchpoints:

• Immediate log (within 24 hours): metric + feeling sentence.
• Reflection log (after 7 days): metric trend + decision (scale/revert/tweak).

We assumed immediate feedback is good enough → observed that 7‑day reflection often reveals delayed effects → changed to the two‑touchpoint rule.

We assumed running many ideas quickly would be best → observed team paralysis from too many parallel probes (context switching costs ~15–30 minutes each) → changed to "one probe per person per 48 hours" policy. That pivot reduced context switching and increased completion rates by ~40% in our trial.

• Safety/legal? If yes → consult.
• Reversible in 24 hours? If no → redesign.
• Measurable with one number? If no → add metric.
• Low setup cost? If no → pilot with a mock.

Alternative path for busy days (≤5 minutes)
If we only have 5 minutes, do this micro‑exercise:

1. Pick a requirement and write it in one sentence.
2. Ask two directional questions: "What if we halve it?" and "What if we double it?"
3. Choose the cheapest change that seems promising (≤2 minutes to set up).
4. Create a single Brali check‑in for tonight: "Minutes saved or count changed?" and one sentence of sensation.

This keeps momentum when time is scarce.

How to log in Brali — exact fields we use

• Title: Probe — [System] — [Requirement] — [Change]
• Due: today
• Check‑in 1 (Daily): Numeric metric (minutes, count, grams)
• Check‑in 2 (Daily): Sensation/brief note (one sentence)
• Weekly reflection (after 7 days): trend and decision

We assumed multiple check‑ins per day improved data → observed that completion rates fell from ~70% to ~30% with more than one check‑in → changed to 1 daily + 1 weekly as the default.

We quantify both sides. For time, use minutes. For frequency, use counts per day. For substance, use grams or mg (e.g., sugar, caffeine). For subjective states, use a 1–5 scale.

Example metrics table (conceptually):

• Time cost saved: minutes/day
• Frequency of interruptions: counts/day
• Substance intake: grams/day or mg/day
• Subjective satisfaction: 1–5

We recommend capturing at least one objective numeric and one subjective rating.

Case study walkthrough — from question to change We walk through an example end‑to‑end, with concrete numbers.

Context: Weekly code review meetings (90 minutes), requirement: "All PRs explained in meeting." Step 1: Write requirement: "All PRs must be explained during weekly review meeting (90 min)." Step 2: Ask directional questions:

• Increase: longer meetings → more context, more time cost (+45 min)
• Decrease: fewer PRs explained → risk of missed context
• Invert: do not explain PRs in meeting; use comments and asynchronous short videos Step 3: Generate candidates (6):

1. 45‑minute meeting with pre-reading (cost: pre-reading time estimate 20 min total)
2. Asynchronous 5‑minute video per PR (cost: 10 min per PR)
3. Rotate PR explainers (cost: spreads knowledge)
4. Keep meeting but limit explanation to top 3 PRs
5. Triage PRs before meeting and remove trivial ones
6. Move to biweekly meeting Step 4: Score and pick (use formula):

• Candidate 4 (limit to top 3 PRs): Impact 8, Feasibility 9, Time 15 → Score = 4.8
• Candidate 1 (45‑minute meeting + pre‑read): Impact 7, Feasibility 6, Time 30 → Score = 1.4 Pick Candidate 4. Step 5: Implement today: change meeting notes to include "Top 3 PRs"; set timer to 45 minutes; inform team. Step 6: Metrics: meeting length (minutes) and number of PRs deferred (count). Baseline: 90 min, 6 PRs explained. Day after: 45 min, 3 PRs explained, 3 deferred. Minutes saved = 45. Impact on code review turnaround time: monitor for 2 weeks. Decision rule: If minutes saved ≥30% and PR turnaround ≤ baseline +10%, adopt.

After two iterations, we found cumulative time saved = 90 minutes/week across the team. Some PRs required more asynchronous comments; turnaround increased 5% (within decision threshold). We adopted the change and added a weekly asynchronous slot for deferred PRs.

Check‑in Block Daily (3 Qs):

• 1. What number did we log today? (minutes saved, count changed, or grams/mg consumed)
• 2. What did we do differently? (one sentence)
• 3. Sensation: On a scale 1–5, how did it feel or perform?

Weekly (3 Qs):

• 1. Trend: Numeric change over 7 days (total minutes saved, total counts, or net grams)
• 2. Consistency: How many days did we apply the probe? (count 0–7)
• 3. Decision: Continue / Scale / Revert? (one sentence justification)

Metrics:

• Primary: minutes saved per day (minutes) OR count change per day (count) — pick one
• Secondary (optional): subjective rating 1–5

Example entries (how to fill):

• Daily: 45 minutes saved; limited meeting to top 3 PRs; felt efficient (4)
• Weekly: 225 minutes saved; 5/7 days applied; decision: scale — rotate owners for top PR selection.

One‑page synthesis rule After a week of probes, create a one‑page synthesis that lists:

• Top 3 winning adjustments, each with numbers (minutes saved, counts, subjective rating)
• One line description of why it worked
• One line of risk or limitation This forces decisions and closes the loop.

Risks and limits — explicit

• We may under‑test rare but severe failures. When stakes are high, increase sample size and consultation.
• Short probes can give misleading early returns due to novelty effects (up to +20% short‑term boost). Use 7–14 day windows where possible.
• When changing physiological requirements (sleep, medication), proceed conservatively, consult professionals if necessary.

• Start with one 30‑minute session per week for 4 weeks.
• During each session, run 1–2 probes and score them as described.
• Log daily check‑ins in Brali (one number + one sentence).
• At the end of the week, synthesize and pick 1 change to scale.

We assumed a continuous weekly cadence would be easy → observed busy calendars block new habits → changed to "block a recurring 30‑minute slot and call it 'TRIZ Lab'". Keep it recurring to reduce friction.

Closing micro‑scene — the end of the day We close the laptop, press the Brali check‑in, and write: "Saved 45 minutes; limited meeting to top 3 PRs; team felt focused (4/5)." We breathe out — a small relief. We did one thing differently, logged one number, and learned. That is the habit: small probes, quick measurements, and honest reflections.

Mini‑App Nudge (again)
Add a Brali check‑in module titled "TRIZ probe — daily numeric + sentence" and set it to appear at 20:00 each day. It will take 30 seconds to complete and will keep us honest.

• Start with personal, low‑risk systems: habits, meetings, reports.
• Keep metrics simple: minutes, counts, grams, mg, or 1–5 subjective rating.
• Limit ideation to six candidates and pick the highest score using (Impact×Feasibility)/Time.
• Use reversible changes early; escalate only when evidence supports it.
• Keep a one‑line lesson for each failed probe.

Check‑in Block (copy into Brali LifeOS)
Daily (3 Qs):

• Q1: Numeric result today (minutes saved OR count change OR grams/mg): ______
• Q2: What did we change? (one sentence): ______
• Q3: Sensation/quality (1–5): ____

Weekly (3 Qs):

• Q1: Total numeric change this week (sum of daily numbers): ______
• Q2: Days applied this week (0–7): ____
• Q3: Decision: Continue / Scale / Revert? (one sentence): ______

Metrics:

• Primary: minutes saved per day (minutes) OR count change per day (count)
• Secondary (optional): subjective rating (1–5)

Alternative path for busy days (≤5 minutes)

• Pick one requirement, ask: "What if we halve it?" and "What if we double it?"
• Pick the cheapest change (≤2 minutes), set a single Brali check‑in for tonight with one numeric and one sentence.