> ## Documentation Index
> Fetch the complete documentation index at: https://docs.within.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Maintaining your process attributes
> Where the numbers on a process node come from, how much they can be trusted, and how to raise confidence in the ones a decision depends on.
export const NeedHelp = () =>
Need help? Use the in-app chat — click the chat bubble in the bottom-right corner of Within (staffed 24×5) — or email support@within.ai.
;
Every number on a process node — how long a run takes, how often it happens, how many times a year — is an **attribute**. Attributes are what Advisor does arithmetic with, so they decide whether a time-savings estimate is solid enough to take to a steering committee or only good enough to pick where to look next. This page covers what attributes are, which of the four capture paths writes to them, and how to raise your confidence in a specific number when a decision depends on it.
**You don't need an accurate number — you need one accurate enough for the decision in front of you**, and you need to know which one you have. This page is about what the fields are and how to move them. For how much precision a given decision warrants, see [How Advisor uses your process attributes](/user-docs/improve/advisor-process-attributes).
## Start where your question is
The fields on a node, and the four timing ones people most often confuse.
The four capture paths, and how much each one had to deduce.
Match the effort to the decision. Most precision-chasing is wasted here.
Cheapest first, and what doesn't work however many times you try it.
## What an attribute is
A process node isn't a single record — it's an evolving series of versions and process observations. Each version holds the process definition (objective, description, value stream, team) and the process contains a set of **attributes**: the structured fields describing how the process *behaves*, rather than what it does.
Every version also records its own provenance:
* **What produced it** — a capture agent, or a person.
* **Which session it came from** — the specific Companion session, interview, or upload.
* **What changed and why** — a short change note carried with the version.
* **When it took effect**, and whether it's the current version.
That provenance is what makes "how much should I trust this number?" an answerable question rather than a matter of taste. When a figure looks wrong, the first move is to find which version set it and where that version came from.
**Timing and volume**
* **Cycle Time** — total time for one iteration, start to finish (inclusive of wait time). A single value with a unit.
* **Active Work Time** — approximate hands-on work in one iteration.
* **Frequency** — recurrence cadence (`Daily`, `Monthly`, `~500/year`).
* **Annual Volume** — total count of times that process is executed from start to finish per year.
**Classification**
* **Descriptive Process Name** — a concise restatement capturing task, tools and outcome.
* **Key Control** — whether this process prevents, detects or corrects error, fraud or non-compliance.
* **Teams Involved** and **Systems Used** — the teams participating and the systems touched.
**Narrative**
* **Purpose & Objectives**, **Process Overview**, **Scope**, **Prerequisites**, **Roles and Responsibilities**, **Exception Handling**, **User Expressed Pain Points**.
Which attributes get captured at all, and how the captured material is interpreted into them, is set by the template you capture with and by your Context Store rules. The set above is the default shape, not a fixed schema for every workspace.
## The four timing attributes that are fairly adjacent
This is where most "the cycle time looks wrong" questions actually land. Four different fields answer four different questions:
| Attribute | The question it answers | Shape |
| - | - | - |
| **Cycle Time** | How long does one run take, start to finish? (Inclusive of waiting time) | One number + unit |
| **Active Work Time** | How much hands-on work is in one run? | A range |
| **Frequency** | How often does it run? | A cadence |
| **Annual Volume** | How many runs a year? | A count |
**In short:** if a figure looks unstable, check which of the four you're reading before concluding the data is wrong. Elapsed time and hands-on time diverge sharply on any process with waiting, approvals or batch windows — and that divergence isn't noise, it's the finding. Active Work Time is a *range* by design, so a spread there is the field working, not failing.
### What Cycle Time is actually for
Cycle Time is not the input to your savings arithmetic — Active Work Time is (see [How Advisor uses your process attributes](/user-docs/improve/advisor-process-attributes)). Cycle Time earns its place for a different reason: it is the only way to see the dead air.
```text theme={null}
Wait Time (+ Rework) = Cycle Time − Active Work Time
```
You never measure wait time directly. You back into it from that gap. A run with twenty minutes of hands-on work and a three-day cycle time is telling you something that matters, and none of it is in the twenty minutes.
Wait time and defects are the two hardest of the classic wastes to trace, which is exactly why they're worth the trouble. Hands-on work announces itself — someone is visibly doing it. Waiting and rework hide in the gaps between tasks: a queue, an approval sitting in an inbox, a handoff that bounced back. Drop Cycle Time and you don't solve that problem, you just stop measuring it — and it resurfaces later wearing a different label.
**How to read Cycle Time:** as a directional signal for where wait time and rework are hiding — **not as a precise SLA**. Treat a large gap between Cycle Time and Active Work Time as a place to go and look, not as a number to commit to. And only stamp Cycle Time on a node when your confidence in it is genuinely high: a guessed Cycle Time produces a *confidently wrong* wait time, which is worse than leaving the field empty.
Two practical notes. First, the gap is only as good as the end of the Active Work Time range you subtract — take the top of the range and you'll derive near-zero wait; take the bottom and you'll overstate it. Pick one convention and say which you used. Second, friction a Companion session catches — a re-authentication, a file locked by a colleague, an approval you sat waiting on — is wait time by definition: it belongs in the gap, not in the hands-on figure.
## Where the values come from
Four paths write to the attribute fields, and they differ in **level of inference** — how much the platform had to deduce versus how much it was simply told.
**Low inference means there is a high level of confidence that a human actively declared the value.** High inference means the figure was derived from watching work happen with nobody naming it, which buys much broader coverage at the cost of precision. Neither end is wrong, but they answer different questions — and when two sources disagree about the same field, **the higher-confidence one wins.**
The cards below are labelled by **confidence** — how far you can trust the figure — which runs opposite to inference. Ranked highest confidence to lowest, read left to right, top to bottom:
A person sets the value directly. Nothing is interpreted — the number is what someone stated it is.
A Subject Matter Expert states the figure on the record, for a process. Interpreted from speech, but the figure was given rather than deduced.
The figure is read out of material you supplied. Higher confidence where the document states it outright; lower where it has to be timed off a recording.
Timing is deduced from observed work across sessions, with nobody stating a number. Broadest coverage, most inference, most conservative updates — trust any single figure least.
Setting the value yourself creates a version whose provenance is a person rather than an agent, with nothing deduced in between. This is the lever to reach for when a decision depends on the number.
Find the process in the Process Index and open it.
Change the value on the attribute you need to correct.
Say where the number came from and what it covers — for example, *"time study across 20 runs, Aug 2026, excludes month-end."* A value with no stated basis is hard to defend three months later and impossible for anyone else to audit.
Editing an attribute doesn't stop Companion from updating the node as new sessions arrive. To hold a figure fixed, see [Set your process standard (UDS)](/user-docs/advanced/using-a-user-defined-standard).
An interview produces a number a person said out loud. That's a different kind of evidence from an observation: precise about the definition, unverified against reality. It's the fastest way to get a defensible figure onto a node, and the right tool when you need one specific process quantified now rather than in a month.
To make it useful, have the expert state the number **with its basis**: *"a normal one takes about twenty minutes; month-end runs take two hours."* A bare "about twenty minutes" gives you a point with no distribution — and the distribution is usually the part that decides the business case.
**Q\&A Mode is the mode that draws metrics out.** Observation Mode captures what you volunteer. If a figure matters, run the session in Q\&A Mode and say the number out loud.
A pre-recorded video gives one observed pass, with the same caveat as a single Companion session. A document gives the figure the document *claims* — which is the intended number rather than the observed one, and worth capturing precisely because comparing intent against observed reality is often the finding.
A Companion session doesn't replace what's on the node. It creates an **observation** against the node, and the timing attributes are merged rather than overwritten. The merge is deliberately cautious, and it's the most common source of "why hasn't the number moved?":
* A **partial or interleaved pass** — you handled two cases, then switched tasks — leaves the timing attributes where they were. A fragment of a run isn't a measurement of a run.
* An **atypical heavy pass** — a month-end batch that takes four times a normal day — widens Active Work Time to cover it and leaves Cycle Time on the representative case, rather than letting one outlier move the headline figure.
* Each observation records what deviated from the usual path, so an unusual run stays visible *as* an unusual run instead of being quietly averaged in.
**In short:** the variance you see across Companion sessions is the merge being careful, not the data being unreliable. It's also why re-running the same capture hoping the number settles doesn't work — see [Raising confidence deliberately](#raising-confidence-deliberately) below.
The practical consequence: to get timing that reflects reality *including* the hard weeks, let Companion run across at least one full cycle of the process — a whole month for anything with a month-end shape — and read Active Work Time as a range rather than Cycle Time as a point.
## What Advisor does with these numbers
Advisor does arithmetic with these fields — `Active Work Time` × `Annual Volume` for effort, and the gap under Cycle Time for wait and rework. How much precision that arithmetic needs depends entirely on the decision you take it to, and different kinds of value case lean on different attributes.
Which fields Advisor reasons over, how much accuracy each kind of decision actually needs, and where to spend your effort.
## Raising confidence deliberately
Cheapest first. Stop as soon as the number is good enough for the decision.
1. **Say the number during capture.** Narrate metrics as they come up — "this normally takes me about twenty minutes, but month-end is a couple of hours." This costs nothing and it's the highest-leverage habit on this page. See [Best practices for narration and pacing](/user-docs/discover/narration-and-pacing).
2. **Let Companion run across a full cycle.** One month of sessions on a monthly process turns a single point into a range that covers the atypical passes.
3. **Run a targeted interview on the processes that matter.** You don't need this for every node — just the handful carrying the mass. Use Q\&A Mode.
4. **Set the value directly and record why.** For anything going into a funded case.
5. **Pin it as a standard.** For anything that must not drift, or that an auditor will read.
**What doesn't work: re-running captures until the number looks right.** The merge is conservative by design — a partial pass won't move a timing attribute however many times you run it. If a figure is wrong, correct it directly and record the basis.
## Good to know
* **Attributes roll up.** Hovering a column in the Process Index shows a node's attributes *including its children's*. Check which level you're reading before you compare two numbers.
* **An empty attribute isn't a zero.** A blank Annual Volume means nobody has said yet, not that the process never runs. Advisor treats it as unknown; so should you.
* **A range is a feature.** Active Work Time is meant to hold a spread. Collapsing it to one number throws away exactly the information you'd need to size a worst case.
* **Cycle Time and Active Work Time are a pair.** Populating only one of them costs you the wait-time signal entirely — there is nothing to subtract from, or nothing to subtract.
* **Templates decide what gets captured.** If an attribute you care about is never populated, the template may simply not ask for it — see [Using and editing templates](/user-docs/advanced/using-and-editing-templates).
* **Context Store rules shape interpretation.** If captures consistently mis-read a figure — wrong unit, wrong scope — that's usually a Context Store fix rather than a capture problem. See [Refining the context store](/user-docs/advanced/refining-the-context-store).
## FAQ
Almost always because the session wasn't a representative full run. If you handled part of the work, switched tasks, and came back, the merge treats that as a fragment and leaves the timing attributes alone rather than moving them on partial evidence. Capture one clean end-to-end run, or set the value directly and record the basis.
Because they're doing different jobs. Active Work Time is the hands-on effort you multiply by volume to size a saving, and it genuinely varies run to run — so it's held as a range that widens as more passes are observed. Cycle Time is a single representative elapsed duration, and its job is to be *subtracted from* rather than multiplied: the gap between the two is your wait time and rework. If you need one effort figure for a model, take it from the Active Work Time range and state which end you used — then use that same end consistently when you derive wait time.
There isn't one, and there won't be — wait time isn't directly observable, so it isn't stored. You derive it: **Cycle Time − Active Work Time**. That gap is where queues, approvals, handoffs and rework live. It's also the reason both fields are worth populating even though only one of them feeds your savings math. Read the result as a pointer to where to look, not as a committed figure — see [What Cycle Time is actually for](#what-cycle-time-is-actually-for).
Yes — bulk operations cover metadata updates across multiple processes, and many of these changes can be made conversationally: describe what you want and Within proposes a plan you review before it runs. See [Using AI Chat](/user-docs/improve/using-ai-chat) and [Process Index: a deeper dive](/user-docs/structure/process-index-deeper-dive). Bulk-setting a timing figure across processes that don't actually share it is a fast way to make an index look precise and be wrong — set the ones that matter individually.
Only if you ask. It reasons around gaps rather than refusing to answer, so an analysis over a thinly populated index still returns a confident-looking report. Add *"Include any assumptions or gaps"* to the prompt and it will name what it didn't have.
Actuals. A process node is a living representation of observed work — that's the point of it. If you want to hold an approved target as well, that's what a user-defined standard is for: the standard holds the target, the observed node holds reality, and Advisor can compare them. See [Set your process standard (UDS)](/user-docs/advanced/using-a-user-defined-standard).
Observed attributes maintain themselves as long as Companion is running — that's the default and it needs no attention. Manually set figures don't: they stay exactly as you left them while the work underneath changes. Anything you set by hand for a funded case is worth re-checking when the process, its systems, or its volume changes materially — and worth a look before you reuse the figure in a new decision.
## Related articles
How the hierarchy is built and how nodes are organised.
The structural habits that make Advisor reason well.
How much precision your decision needs, and which fields carry it.
The three capture methods that populate these fields.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.