How to Compare the Ideal State of Your System with Its Actual State to Find Where (TRIZ)

We could spend weeks brainstorming causes. Or we could define the ideal, measure the actual now, and find the smallest high‑impact mismatch. The decision we make at the start changes everything: if we spend more time describing the ideal than measuring the actual, we get elegant but unusable plans. If we rush to metrics without a clear ideal, we fix noise.

So our decision right now: spend 20–45 minutes to define one ideal and capture five actual data points. That small investment creates directional clarity. Today’s first micro‑task (≤10 minutes) is below; we will scale from there.

First micro‑task (≤10 minutes):

• Open Brali LifeOS and create a task: “TRIZ: Ideal vs Actual — first pass”.
• Write a single sentence for the system's ideal state. Keep it simple: “Our build server completes all tests within 30 minutes and requires no manual intervention.”
• List three quick observations of the actual state in short fragments: “Average test runtime 85 minutes; 2 manual restarts per week; 18% flaky test rate.”
• Save and set a check‑in for tomorrow: 5 minutes to verify metrics.

We will return to that task later. For now, continue reading to see how each choice unfolds into action.

When we say “system,” we must immediately choose what’s in and out. The boundary is the most common point of subtle failure: we include too much (the whole company) or too little (one script). Boundaries matter because they decide which variables we’ll measure and which trade‑offs we can control.

Micro‑sceneMicro‑scene
we are at a whiteboard with a faded diagram of an app stack. We sketch three concentric circles: feature code, CI pipeline, deployment. We debate for two minutes and then pick the middle circle — CI pipeline — because it’s where tests, runtime, and stoppages live. We could have picked an endpoint — the whole delivery pipeline — but that would require stakeholders we can’t reach today.

Action now: choose a boundary in Brali LifeOS task notes and add one justification sentence. Example: “Boundary: CI pipeline between commit and deploy — we can measure runtimes and control test parallelism.”

Trade‑off to note: a smaller boundary gives faster learning but risks missing upstream causes. A larger boundary finds systemic causes but delays action. If we have limited time, choose smaller.

Ideal states should be crisp, preferably with a number or a binary outcome. “Runs smoothly” is not an ideal. “Less flaky” is not either. We prefer something like “90% of builds finish within 30 minutes with zero manual intervention.”

Why numbers? They convert feelings into targets and let us compare across days. We will often pick a primary metric (one number) and a secondary metric (optional).

Guiding questions as we write the ideal:

• What metric best captures usefulness? (uptime, minutes, counts)
• What’s the acceptable threshold? (30 minutes, 95% success)
• What’s the time horizon? (per day, per week)

Micro‑sceneMicro‑scene
we try two versions. “All tests run under 30 minutes” vs. “95% of commits produce a green build within 30 minutes.” We choose the latter because it allows for rare exceptions. That is our explicit pivot: We assumed “all commits should be green” → observed it was impossible due to external flaky tests → changed to “95% within 30 minutes.”

Action now: in Brali LifeOS, edit the task and write the precise ideal using a number. Example: “Ideal: 95% of builds finish within 30 minutes with no manual intervention.”

Measurement need not be perfect. The point is to capture the signal. We will collect a small sample (3–10 data points) or use an existing dashboard. If only manual logs are available, take a timed sample over the next day.

Options and trade‑offs:

• Automated logs: precise, but may require permissions.
• Manual sample: fast, may be noisy.
• Stakeholder interview: helps explanation but brings bias.

Micro‑sceneMicro‑scene
we grab the last 10 build records from the CI dashboard and export runtimes and failure reasons. We note runtimes: 35, 92, 28, 46, 81, 30, 120, 27, 33, 55 minutes; failures: network timeout (3), flaky test (2), infrastructure restart (1). We compute the 95th percentile: roughly 120 minutes; the median: ~40 minutes. Only 4 of 10 builds meet the 30-minute target (40%).

Action now: import or paste a short table into the Brali LifeOS task notes or journal. Record at least five actual numbers and a brief note about how you collected them.

We now compare the ideal number(s)
to the actual distribution. Two simple comparisons matter:

• Frequency gap: what percentage of events miss the target?
• Magnitude gap: by how much (minutes, count) do misses exceed the target?

We prefer frequency for prioritising because a 1% failure that wastes 10 hours is different from a 30% failure that only adds 5 minutes. Both matter, but frequency usually highlights consistent weaknesses.

Micro‑sceneMicro‑scene
with our ten builds, 6 missed the 30‑minute target. Frequency gap = 60% vs ideal 5%. Magnitude gap among misses: average exceedance ~45 minutes (e.g., a build taking 75 minutes averages +45 over the 30-minute target). This identifies a clear opportunity.

Action now: calculate two numbers in Brali LifeOS notes: “Frequency miss = 60% (target ≤5%); Average excess time among misses = 45 minutes.”

We can investigate causes (why tests are slow?)
or patch the symptom (parallelise tests). The right choice depends on time and leverage.

If we have ≤2 hours today, choose a patch that is easy, low‑risk, and measurable: e.g., enable test parallelism or cache dependencies — changes that require <1 hour of dev time and a rollback. If we have more time or the cost of a failed patch is high, do a 30‑60 minute root cause interview and log an experiment.

Micro‑sceneMicro‑scene
we discuss and choose a low-risk patch: enable caching for dependencies which historically reduces runtime by ~20–40%. We also plan a small experiment: clear the cache weekly to ensure integrity.

Action now: create a small Brali task: “Experiment A: Enable dependency cache for CI.” Set it to 60 minutes and add acceptance criteria: “Median build time reduces by ≥15 minutes in 3 runs.”

We will run an A/B or before/after for a small window: three consecutive builds or one workday. Keep the experiment simple and reversible.

Elements to record for each experiment run:

• Baseline metric value (minutes, counts)
• Change applied
• Number of trials (3–5 typical)
• Acceptance criteria (e.g., reduce median time by ≥15 minutes or reduce misses from 60% to ≤30%)

Micro‑sceneMicro‑scene
we note baseline medians and decide: run the patch over five builds during the next working day. We will compare median times, percent below 30 minutes, and note new failure modes.

Action now: in Brali LifeOS, create a checklist for the experiment:

• Note baseline medians
• Apply patch
• Run 5 builds
• Record times and failure reasons
• Evaluate vs acceptance

Every fix may introduce new risks: caching could lead to stale artifacts; parallelism might hide flaky tests; aggressive timeouts might cause false positives. Record these potential failure modes and a rollback plan.

Micro‑sceneMicro‑scene
the team writes three one‑line failure modes on a sticky note: “stale cache → false passes; increased IO when parallelising → resource starvation; non-deterministic test order → hidden flakiness.” For each, we state a rollback: clear cache, revert parallelism, restore original test execution order.

Action now: add the three failure modes and rollbacks into the Brali task as bullet points. This makes the experiment safer and faster to reverse if it fails.

When we run, we watch for context: network load, concurrent builds, external API slowness. These contextual signals often explain outliers.

Micro‑sceneMicro‑scene
on run day we note a noisy external API was down for two hours; one of the long builds corresponds to that outage. We log this as “external outage” and exclude it from the core analysis if it’s unrelated to our patch.

Action now: for each trial build, log three short facts: runtime (minutes), pass/fail, and one context note (e.g., “external_api=slow”, “cache_hit=true”).

We will compute two descriptive statistics: median and frequency below target. If the median drops and the frequency of misses decreases, the patch likely helped. If not, we revert and try the next idea.

Micro‑sceneMicro‑scene
after five runs, median drops from 40 to 28 minutes; frequency below 30 minutes increases from 40% to 70%; flawed runs show no new failure modes. We declare the patch a partial success and decide to keep caching enabled while scheduling a deeper root‑cause analysis for remaining slow tests.

Action now: in Brali LifeOS, update the experiment task with results and check the box if acceptance is met. Add a 15‑minute reflection entry: “What surprised us? What next?”

We must prioritise further work. We rank candidate fixes by two numbers: expected impact (minutes saved or percent reduction in misses) and expected cost (hours of dev/test). Prefer fixes with impact/cost ratio > 1 (minutes saved per hour of work, or a subjective multiple like “≥3x”).

Micro‑sceneMicro‑scene
we list three next ideas and roughly estimate:

• Parallel test shards — Impact 20 minutes, Cost 3 hours → 6.7 min/hour
• Remove 10 slow tests — Impact 45 minutes, Cost 6 hours → 7.5 min/hour
• Stability fixes for flaky tests — Impact 60 minutes, Cost 10 hours → 6 min/hour

We prioritise removing slow tests first, because the ratio is highest and the work is straightforward.

Action now: create a priority table in the Brali task and pick one next micro‑task (≤2 hours). Set a deadline in Brali.

Numbers give clarity but not complete explanation. Sometimes tests are slow because someone committed a large dataset or a debug flag. If the numbers don’t explain a pattern, ask one person who knows the area. A ten‑minute conversation can reveal the root cause faster than three hours of blind changes.

Micro‑sceneMicro‑scene
we see a cluster of long builds and call the developer who touched that module. They admit they temporarily increased logging and forgot to revert it. We revert the logging and immediately notice builds drop by 15 minutes.

Action now: if a suspicious cluster appears, add a Brali note: “Call or message the last committer — 10 mins.” Schedule it as a quick follow‑up.

We promised numbers. Here is a realistic Sample Day Tally for a CI pipeline target: “95% of builds finish within 30 minutes.”

We start the day with:

• Baseline: 10 builds in last 24 hours. Runtimes (min): 35, 92, 28, 46, 81, 30, 120, 27, 33, 55. Median = 40 min. 4 builds ≤30 min → 40% success. Our mini‑interventions during the day:
• Enable dependency cache (+ commit) — estimated effect: -15 min median
• Disable verbose logging flag in one module — estimated effect: -12 min on known builds
• Remove a single slow test from the suite and mark it 'flaky' — estimated effect: -20 min on affected builds

Post‑changes, run 5 new builds:

• New runtimes: 28, 31, 29, 34, 26 → Median = 29 min. 4 of 5 ≤30 min → 80% success.

Tally (summaries):

• Total builds sampled: 15
• Baseline median: 40 min
• Post‑intervention median: 29 min
• Net median change: -11 minutes
• Success frequency at target (≤30 min): from 40% → 80%

This shows a practical day of action with explicit returns. If you only have 5 minutes, apply the tiny path below.

If we have five minutes or less, do this:

• Open Brali LifeOS and add one note: pick the single metric you care about (minutes, count).
• Capture the latest build time and one context note (e.g., “network slow”).
• Create a single task: “Enable caching or message last committer” with 5-minute estimate. This keeps momentum without heavy work.

Mini‑App Nudge: create a Brali quick check‑in that asks: “Today’s build time (minutes)?” and “One context note?” — use that micro‑module each morning.

We must call out several common misunderstandings.

Misconception 1: The ideal must be perfect. Reality: Ideals are direction sentences with a numeric target and an allowance for rare exceptions (95% vs 100%). Absolute perfection is usually unattainable and wastes effort.

Misconception 2: More metrics are better. Reality: Too many metrics dilute focus and invite gaming. Pick one primary metric and one secondary context metric (minutes and flakiness count).

Misconception 3: Quick patches are always harmful. Reality: Some quick patches (caching, rollback strategies)
give immediate gains and reduce noise, enabling deeper fixes later. They must, however, be reversible and instrumented.

Edge case: when the actual data is sparse (fewer than 5 events). Action: widen the time horizon to a week or aggregate similar events. If you still have sparse data, prioritise qualitative checks (interview the person who runs the process).

Risk/limits: Correlation ≠ causation. If build times drop after a change, verify the drop persists across additional runs (3–10 runs) and check for confounders (e.g., external service outage returning to normal).

We assumed the problem was test execution order causing delays (X). We looked at data and observed that large commits with added logging correlated with the longest runtimes (Y). We changed to a focused quick patch: revert logging and enable caches (Z). That pivot saved ~11 minutes median time in our Sample Day Tally and gave us breathing room to plan deeper fixes.

This method works best when repeated weekly. We recommend a lightweight cadence: a 15‑minute weekly check to compare ideal vs. actual and adjust one micro‑task.

Why weekly? Weekly captures slow trends without being noisy. Too frequent (daily)
and we chase noise; too infrequent (monthly) and we slow learning.

Action now: add a recurring weekly Brali task: “TRIZ gap review — 15 min.” Put it in the calendar and attach the metric snapshot.

After each experiment, we write two sentences:

• What changed and why (one sentence).
• What we observed and what we’ll do next (one sentence).

Micro‑sceneMicro‑scene
we write in the Brali journal: “Enabled dependency cache because cold installs dominated runtime. Observed median drop from 40 → 29 min; next: remove slow tests and schedule flakiness fixes.”

Action now: add this two‑sentence entry to the Brali task after each experiment.

Once the method produces reliable improvements, the question becomes how to scale the approach to multiple systems without losing clarity.

We recommend a lightweight portfolio:

• Up to five systems with one primary metric each.
• Weekly micro‑sprints: pick the system with the largest gap × feasibility score.
• Monthly review to align resources and retire systems that no longer move the needle.

Trade‑off: scaling increases coordination cost; keep each system owner accountable with a weekly 5‑minute check‑in.

We prefer 1–2 numeric metrics:

• Primary metric (required): the measure of functional usefulness (minutes, counts, mg, percent).
• Secondary metric (optional): frequency of failure or flakiness (count per day/week).

Examples:

• Build pipeline: Primary = minutes to green, Secondary = flaky test count per week.
• Machine uptime: Primary = minutes/hours of downtime per month, Secondary = number of unscheduled restarts.
• Personal habit (e.g., sleep): Primary = hours slept, Secondary = number of awakenings.

Action now: in Brali LifeOS, enter your two metrics as numeric fields on the task so you can track them across check‑ins.

We favour a pattern that balances attention and effort:

• Daily (1–5 minutes): quick snapshot of primary metric and one context note. Good for fast feedback systems.
• Weekly (10–20 minutes): run one experiment or plan a micro‑task.
• Monthly (20–45 minutes): portfolio prioritisation and resource alignment.

If your system is slow-moving (e.g., monthly hardware failures), reduce frequency accordingly. If it's responsive (CI builds), use daily snapshots.

We apply the same logic to a personal morning routine. Imagine our ideal: “Start work at 9 a.m. feeling alert for at least four productive hours.” Actual: we wake at 8 a.m., sip coffee, check email, feel foggy until 10:30.

We specify the primary metric: time from wake to clear start (minutes). Baseline: 90, 120, 80, 95, 100 minutes across five days; median = 95. Ideal: ≤30 minutes for 80% of days.

Small experiment: remove morning email for three days and do a 10-minute light exercise. Result: median dropped to 35 minutes; adherence 60% — partial success. Next step: tweak exercise intensity and add a 5-minute planning ritual.

The method is identical: define, measure, patch, check, iterate.

We can add social nudges: a colleague check‑in, a small accountability note in Brali LifeOS, or a time‑bound standing calendar event. These increase adherence by roughly an estimated 20–30% based on behavior change patterns.

Micro‑sceneMicro‑scene
we asked one teammate to monitor the CI for a day and log anomalies. Their presence alone made us more disciplined about small rollbacks and reduced noise.

Action now: invite one teammate to one Brali check‑in this week as a short experiment.

TRIZ emphasises contradictions — improvements that create new problems. We will name likely contradictions and predefine mitigations.

Example contradictions and mitigations:

• Improve speed (parallelise tests) → increases load and flakiness. Mitigation: stagger shards, increase worker capacity by 20%.
• Reduce manual intervention → hides subtle issues. Mitigation: add lightweight monitoring alerts for abnormal patterns.

Write these contradictions in the Brali notes so they are visible during planning.

We use the following tiny templates in Brali LifeOS:

• One‑sentence Ideal: “95% of X ≤ Y minutes.”
• Five‑data quick capture: list runtimes and context tags.
• Experiment card: change, trials, acceptance criteria, rollback.
• Two‑sentence journal entry: change+why; observation+next.

Action now: copy these to your Brali LifeOS task description so they are ready for reuse.

Stop when one of these conditions holds:

• The primary metric meets the ideal for 2–4 weeks.
• The cost to further improve exceeds expected benefit (e.g., >10x hours per minute saved).
• System owners reassign priority.

Otherwise, keep iterating with the same micro‑experiment pattern.

Involve additional stakeholders if:

• The solution requires >8 hours of combined work.
• The change could impact other systems (risk of cascading failures).
• The problem spans functions (e.g., dev + ops + QA).

If you involve others, prepare a crisp 5‑minute briefing and the Brali LifeOS experiment card so they can quickly understand the goal and acceptance criteria.

If stakeholders present conflicting ideals (one wants fastest builds; another prioritises stability), create a combined target or a weighted prioritisation: 70% stability, 30% speed, or schedule separate pipelines for fast feedback vs. full stability. Quantify the ratio and log it in Brali.

If a single event is slow, go through a 5‑step check:

• Is there an external outage? (yes/no)
• Is the last committer known? (message them)
• Any recent config changes? (revert temporarily)
• Any increased logging or debug flags? (revert)
• Did the environment hit resource limits? (increase worker memory temporarily)

Record the answers in Brali as quick tags.

We are honest: some improvements require investment (more machines, paid tiers), and not all organisations can accept the cost. We must account for trade‑offs explicitly. If procurement or budget is the constraint, quantify the cost estimate and expected benefit and present it as a small business case: “Spend $500/month to reduce developer waiting time by 11 minutes median, saving ~X hours/week across N devs.”

Action now: create a simple cost/benefit line in Brali if budget is needed.

Our recommended habit:

• Daily: 1‑minute capture (if system is fast-moving).
• Weekly: 15 minutes — one experiment or prioritisation.
• Quarterly: 30–45 minutes — portfolio review.

Start with the weekly 15‑minute block and keep it for eight weeks. If after eight weeks you don’t see cumulative improvement, reassess the system boundary and metrics.

• Risk of overfitting to the sample: use at least 3–5 trials.
• Risk of masking failures with quick patches: keep rollback plans and monitors.
• Risk of stakeholder mismatch: keep ideals visible and revisit them if priorities change.

We always prefer reversible, monitored experiments because they let us learn quickly without breaking things.

We sit with the laptop closed for a minute, the Brali task open. We breathe. We have one ideal sentence, five actual numbers, an experiment card, and a check‑in scheduled. The path ahead is not perfect, but it is small and measurable. That is usually enough to start.

Mini‑App Nudge: add a Brali quick check‑in module that asks each morning: “Primary metric (minutes)?” and “One context note?” — answering takes ≤30 seconds and will keep your comparisons current.

Check‑in Block Daily (3 Qs):

• What was the primary metric today? (minutes or count)
• What felt different in the system? (one short context word: “cache_hit”, “external_outage”, “verbose_logging”)
• Did we apply any change today? (yes/no, short note)

Weekly (3 Qs):

• How many experiments did we run this week? (count)
• What changed the metric the most? (brief description)
• What is the next micro‑task this week? (one lined action, ≤2 hours)

Metrics:

• Primary: Minutes to target (e.g., minutes to green)
• Secondary: Count of failures or flaky incidents (per week)

Simple alternative path for busy days (≤5 minutes)

• Capture one current metric value and one context note in Brali.
• Create a single 5‑minute task: message the last committer or enable a cache toggle.
• Schedule the weekly 15‑minute review if possible.

We will check in tomorrow: did you capture the five numbers and write an ideal sentence? If not, add that first micro‑task and set a 10‑minute timer. We will refine the experiment after you collect the initial data.