pqrst-practice/history/20260905-PqrstEstimationPractice_grok.md

# PQRST Estimation Practice

A retrospective effort topology for agentic coding sessions.

PQRST-Estimate is a deliberately simple lens. It does not claim to measure tokens, wall-clock time, or compute. It records a comparative judgment of where a session’s *effective engineering attention* went, so that many sessions can be observed as a process rather than as isolated chats.

Use it at the end of a session. Collect it consistently. Interpret patterns over time.

---

## Definition

**PQRST-Estimate** is a retrospective estimate of the relative distribution of productive session effort across five engineering concerns.

It is an *assessment*, not telemetry.

| It is | It is not |
| --- | --- |
| A semantic allocation of attention | Elapsed time |
| A 100% comparative split | Token or tool-call accounting |
| Auditable with a short justification | An objective measurement |
| Useful in aggregate across sessions | A target to optimize in advance |

Percentages exist to make a qualitative judgment compact and comparable:

> “This session was research-heavy, moderately implementation-heavy, and contained little security work.”

---

## Dimensions

Keep exactly five dimensions. If more detail is needed later, expand a letter into subdimensions. Do not grow the acronym.

| Letter | Name | Counts as | Does not count as |
| --- | --- | --- | --- |
| **P** | Problem | Direct implementation and problem solving toward the requested outcome | Setup, exploration, verification, planning |
| **Q** | Quality | Tests, debugging, verification, robustness, correctness-oriented refactoring | Greenfield feature work that happens to compile |
| **R** | Research | Domain, repository, APIs, prior work, requirements, ambiguity resolution | Implementation that follows from already-clarified context |
| **S** | Security | Credentials, permissions, secrets, attack surface, policy and security constraints | Generic error handling with no security implication |
| **T** | Task organization | Planning, decomposition, tracking, coordination, tool and workflow management | The planned work itself once execution starts |

Overlaps are expected. Allocate by *primary purpose of the attention*, not by file type. A test written to discover the spec is mostly **Q** with a note that it also reduced **R**. Reconstructing architecture before writing code is **R**, not **P**.

**S** may legitimately be `0`. Do not inflate it to make the model look complete.

---

## Derived views

These are interpretive, not extra dimensions.

| View | Formula | Use |
| --- | --- | --- |
| Problem Focus | `P` | How much of the session was the nominal work |
| Direct Engineering | `P + Q` | Building and hardening the thing |
| Enabling Effort | `R + S + T` | Making the thing possible, allowed, and organized |

Do not call Enabling Effort “waste” or “overhead.” Research and security can be the most valuable work in the session. The question is whether the *mix* fits the class of task.

Healthy is contextual:

- `P90 Q2 R3 S0 T5` can be worse than `P55 Q30 R10 S0 T5`
- Do not maximize **P**. Learn what good signatures look like per task type.

---

## When to collect

Run the estimate once, at the natural end of a session or a clearly bounded work unit (one ticket, one vertical slice, one “stop here” checkpoint).

Do not collect mid-stream unless you are closing a phase on purpose. Mid-session estimates mix unfinished work with planning residue and are hard to compare.

If the session spanned several distinct modes (explore, then implement, then harden), you may emit **one overall estimate** plus optional phase notes. The stored record is still a single 5-tuple unless you explicitly version phases.

---

## Canonical prompt

Paste this at the end of the session. Do not add extra scoring dimensions inside PQRST.

```text
Please give me a PQRST-Estimate for this session.

Allocate exactly 100% of the session's effective engineering effort across:

- P = solving the main problem (direct implementation and problem solving)
- Q = quality, testing, verification, debugging, robustness
- R = research, understanding, repository/API/domain context, requirements clarification
- S = security, permissions, credentials, secrets, attack surface, policy constraints
- T = task organization, planning, decomposition, tracking, coordination, workflow management

Rules:
- This is a retrospective estimate of relative attention, not telemetry of time, tokens, or tool calls.
- Allocate by primary purpose of the work, even when activities overlapped.
- S may be 0 when security was not in scope.
- Percentages must be integers and must sum to 100.

Return exactly this format and nothing else before or after it:

PQRST-Estimate
P: <int>%
Q: <int>%
R: <int>%
S: <int>%
T: <int>%
Sum: 100%
Confidence: <low|medium|high>
Signature: P<int> Q<int> R<int> S<int> T<int>
Dominant factors: <one or two sentences naming the concrete drivers of the largest slices>
Notes: <optional; omit the line if none>
```

Confidence sits *outside* the five-dimensional model. Uncertainty must not be folded into P, Q, R, S, or T.

---

## Canonical result format

### Stored record

Use the block form as the source of truth. The `Signature` line is the compact key for logs, tables, and trend charts.

```text
PQRST-Estimate
P: 25%
Q: 15%
R: 45%
S: 0%
T: 15%
Sum: 100%
Confidence: medium
Signature: P25 Q15 R45 S0 T15
Dominant factors: Repository architecture and implicit module boundaries had to be reconstructed before any implementation; planning the exploration path was a material share of the work.
Notes: Security was out of scope.
```

### Compact line

For transcripts, dashboards, and commit messages:

```text
P25 Q15 R45 S0 T15 | confidence: medium | Repository architecture had to be reconstructed before implementation.
```

Parse rule: five integer fields in P/Q/R/S/T order, optional confidence, then free-text justification.

### Validation

A result is valid only if all of the following hold:

1. Each of P, Q, R, S, T is an integer from 0 to 100 inclusive.
2. `P + Q + R + S + T = 100`.
3. Confidence is one of `low`, `medium`, `high`.
4. `Dominant factors` names *concrete session facts*, not restatements of the percentages.
5. No sixth engineering dimension is introduced in the 5-tuple.

If the model cannot justify a split, prefer coarser rounded tens (`P30 Q20 R30 S0 T20`) and `confidence: low` over fake precision.

---

## Example signatures

These are illustrations, not targets.

```text
P70 Q20 R5 S0 T5
```
Well-understood implementation in a familiar area. Little discovery, some verification.

```text
P25 Q15 R45 S0 T15
```
Exploratory work in an unfamiliar system. Context reconstruction dominated.

```text
P20 Q20 R10 S35 T15
```
Access control, credentials, or security policy dominated the work.

```text
P20 Q15 R20 S0 T45
```
More energy managing the work than doing the work. Inspect agent workflow, task grain, and tool orchestration.

```text
P55 Q30 R10 S0 T5
```
Creation plus real verification. Often healthier than a very high-P session with almost no Q.

```text
P40 Q35 R5 S15 T5
```
Hardening a known surface that includes a security constraint.

---

## Pattern catalog

Interpret *persistence* and *task class*, not a single session.

| Pattern | Possible interpretation |
| --- | --- |
| Persistently high R | Architecture, specification, or repository context is insufficiently explicit |
| Persistently high T | Task grain, agent workflow, or coordination is inefficient |
| Very high P, very low Q | Fast implementation with accumulating verification debt |
| Rising Q late in a project | Stabilization / hardening phase |
| Repeated S spikes | Credential, IAM, or security-ergonomics problem in the environment |
| Falling R over successive sessions on the same repo | Repository knowledge and documentation are improving |
| Falling P, rising Q | Transition from creation to stabilization |
| High Enabling Effort (`R+S+T`) on a supposedly routine change | The environment around P is the real problem |
| High Direct Engineering (`P+Q`) with high confidence | Session matched a well-scoped implementation or hardening task |

A single high-R session on a new codebase is normal. High R on the fifth session in the same module is a process signal.

---

## Correlation ideas

PQRST becomes process telemetry when stored next to outcomes, not when stared at in isolation.

Useful companions:

- task success / partial success / revert
- test energy (tests added, tests run, failures, flakiness)
- human interventions and redirects
- elapsed cost (time or tokens) as a separate column — never substitute it for PQRST
- task type label: `feature`, `bugfix`, `explore`, `migrate`, `harden`, `incident`
- repository or module id

Questions the joined data can answer:

- Do high-T sessions fail more often, or just cost more?
- Does falling R predict fewer human redirects?
- Do high-P / low-Q sessions generate follow-up bugfix sessions?
- Which task types have a stable signature worth using as a baseline?

---

## Practice rules

1. **Estimate after the work, do not steer toward a signature.** PQRST is a lens, not a KPI.
2. **Keep five dimensions.** Expand a letter later if needed; do not add U–Z to the core model.
3. **Write the justification first in your head, then the numbers.** If you cannot name the dominant factors, the split is not ready.
4. **Round to the resolution you can defend.** Integers are required; 1% differences are usually noise.
5. **Leave S at 0 when it was 0.** A forced 5% security slice poisons trend data.
6. **Treat Enabling Effort as context, not guilt.** The diagnostic is misfit to the task, not “too little P.”
7. **Compare like with like.** An explore session and a one-line fix should not share a “healthy” template.
8. **Store the signature line plus the dominant-factors sentence.** Numbers without the sentence are not auditable.

---

## What a good estimate sounds like

Weak:

```text
P: 57%
Q: 14%
R: 19%
S: 2%
T: 8%
Dominant factors: Mixed work across several areas.
```

Strong:

```text
P: 25%
Q: 15%
R: 45%
S: 0%
T: 15%
Sum: 100%
Confidence: medium
Signature: P25 Q15 R45 S0 T15
Dominant factors: Existing auth middleware was undocumented and contradicted the README, so most attention went to reconstructing the request path before changing behavior.
```

The second record can be compared to the next session in the same module. The first cannot.

---

## Minimal operator checklist

At session end:

1. Run the canonical prompt.
2. Confirm the five percentages sum to 100.
3. Keep or reject the result based on whether `Dominant factors` cites concrete session facts.
4. Store `Signature`, `Confidence`, `Dominant factors`, task type, and outcome.
5. Do not discuss the estimate during the next session unless you are changing process on purpose.