Chapter 08: Context Help and System States

One of the defining strengths of 7DEA is that it tries to make state visible. The trust bar, route descriptions, first-session checklists, Aegis path labels, and context-help anchors all participate in that design. Users do not need the hidden mechanics behind every state. They do need to understand what the visible states are telling them and how to act on them.

What the trust bar is telling you

The trust bar is a compact summary of current runtime posture. Publicly, its job is straightforward: it helps the user distinguish what the live system is signaling now from what the user merely expected to be true. System mode, billing mode, build information, and related indicators all exist to reduce guesswork.

Reading the trust bar

Read the trust bar as supporting context, not as a replacement for the route underneath it. Use it to answer questions such as: is this environment live and current, is billing operating in the live posture, and is some part of the workflow governed by a window or delayed publication model? When support needs a reproducible report, the build identifier can also help anchor what the user saw to a specific public experience.

Context help panels

Context help is the bridge between route and manual. It surfaces a small set of anchors relevant to the page you are already on. That is valuable because most mid-workflow questions are not abstract. They are page-bound: why is this locked, what should I do next here, what does this label mean, or where is the deeper explanation?

The public virtue of context help is proportionality. It does not force the user to leave the page and study the entire manual every time something is unfamiliar. Instead, it helps the user interpret the current route in place and then decide whether a deeper chapter is necessary. That makes the manual feel like a working instrument rather than a separate educational product.

Aegis path states

Aegis path labels are public clues about which assistance path is in use. llm_live indicates live route-aware guidance for an entitled account. llm_fallback indicates the controlled invitation path for a non-entitled state. Those labels are not decoration. They help a user tell the difference between expected commercial behavior and a potential mismatch.

The best way to read an Aegis path label is alongside the billing page and the current route. If the account is in explorer mode and the widget shows llm_fallback, that is healthy and commercially coherent. If the account is in active trial or paid posture and the widget still shows fallback, the next step is to check the billing surface and route context before assuming a defect. The label is a clue, not the entire diagnosis.

Billing and entitlement states

Commercial state is one of the most important classes of visible truth in the product. Users should learn to recognize the practical difference between explorer, trial, and paid posture because those states change how Aegis behaves, what export actions are available, and how the dashboard should be interpreted.

Explorer means the user can evaluate the product, read the documentation, and understand the workflow model without consuming live paid assistance. Trial means the user has activated a live evaluation state and can use route-aware guidance while still encountering some controlled limitations. Paid means the account is in durable production posture, subject to the live plan’s capabilities and any ordinary route or artifact state boundaries that still apply.

Deliverable states

Deliverable state is separate from commercial state. This distinction is essential. A paid account can still have a Draft deliverable. A trial account can still produce meaningful structured output even if some downstream distribution actions remain locked. A user will misunderstand the product quickly if they treat “paid” and “ready to export” as synonyms.

The most important deliverable states to read publicly are absent, Draft, Final, and distribution-ready or still-gated. Absent means the work has not yet been created. Draft means a structured artifact exists and can be reviewed. Final means the publication-sensitive stage has completed and downstream actions may now become available if the plan supports them. Distribution-ready means the state and entitlement layers are aligned for the specific export or share action the user wants.

Queued, locked, and finalizing

Not every delay is a failure. 7DEA distinguishes immediate drafting from later publication-sensitive steps. That means a useful Draft may exist while Final publication, PDF readiness, or sharing availability is still waiting. When the product signals a queued or waiting posture, the first question should be whether the current state is actually normal for the stage rather than whether the system has contradicted itself.

A queued state usually means the next stage has not finished yet. A locked state usually means a prerequisite is missing: plan, trial, Final state, or stronger confirmation. Finalizing language usually means you should read the current artifact now and treat later distribution as a separate step.

The crucial discipline is not to flatten all of these into the word “broken.” Queued, locked, and finalizing are different instructions. Queued means wait while preserving the current context. Locked means identify the missing condition. Finalizing means the artifact is in transition and may still be useful for review even if it is not yet ready for every downstream action.

Reading locked controls correctly

A locked control is an explanation wearing the shape of a button. Read the text around it before assuming a defect. The product usually tells you whether the cause is entitlement, trial limitation, deliverable readiness, or security confirmation. Users who learn this pattern save themselves and support teams a lot of unnecessary confusion.

This is one of the deepest context-sensitive-help rules in the entire manual: a control is rarely just unavailable. It is unavailable for a named reason. That reason should drive your next move. If the cause is commercial, go to billing. If the cause is artifact readiness, go to deliverables. If the cause is a stronger identity check, go to account. The lock is already telling you which truth layer matters.

Page ownership matters

When a state feels surprising, ask which route owns the truth for that state. Billing owns commercial posture. Deliverables own artifact state. Account owns sensitive identity and data-rights actions. Dashboard owns signed-in working posture. Aegis helps interpret, but it should not be mistaken for the page that owns every fact.

This page-ownership model is one of the reasons the product stays teachable. Users do not need to memorize internal architecture. They only need to know which visible surface should settle a particular class of question. Once that is clear, state interpretation becomes much calmer and support questions become more precise.

Reconciling state mismatches calmly

Occasionally, two surfaces may appear to tell different stories. The right response is not immediate distrust. The right response is to compare the surfaces by category. Is one talking about entitlement while the other is talking about artifact readiness? Is one describing current route context while the other is describing a downstream action? Many apparent contradictions vanish when the user names the category correctly.

If a true mismatch remains after that check, preserve the evidence carefully: route, visible wording, current commercial posture as understood, time, and the shortest reproduction path. This is also the moment when build identifiers become useful. Calm evidence beats vague escalation every time.

Build identifiers, reproducibility, and calm reporting

Most users do not need to think about build identifiers every day. But when something feels genuinely inconsistent, the combination of route, exact wording, timestamp, and build identifier can turn a fuzzy complaint into a reproducible report. That is why 7DEA surfaces operationally meaningful signals publicly without burying the user in engineering detail.

Practical state-reading checklist

When a page surprises you, use this sequence:

1. Name the route you are on.
2. Read the heading, summary copy, and any nearby trust or status language.
3. Decide whether the state is mainly commercial, artifact-related, account-related, or guidance-related.
4. Check the page that owns that category of truth.
5. Use context help or the matching manual chapter only after the visible state has been read carefully.
6. Escalate only if the visible story still feels internally inconsistent.

This checklist sounds modest, but it captures one of the deepest design ideas in 7DEA: clarity comes from reading states in the right order. Once users learn that habit, the product becomes dramatically easier to understand.