Chapter 02: Aegis Guidance and Guided Onboarding

Aegis is the product’s guided interpretation layer. It is not a generic chatbot pasted onto the interface. Its value comes from route context, visible system state, and commercial truth. When used well, Aegis helps people move from uncertainty to a specific next action without pretending that every answer should be identical for every account.

Because Aegis is part of a commercial product, it behaves differently for different states. Explorers receive a respectful invitation to activate trial or paid access for live guidance. Trial and active paid users are the intended live-guidance states. This distinction is not a hidden technicality. It is a core part of how the system preserves paid guidance capacity while still treating exploratory users professionally.

What Aegis Is Good At

Aegis is strongest when you ask it to interpret the page you are on, explain what a state means, help choose a next route, compare the implications of two commercial states, or guide you through the early parts of deliverable creation. It is especially helpful during onboarding because the product’s surfaces are explicit but layered. New users often benefit from one additional voice saying, in effect, “Here is what this page means, and here is the safest next move.”

Aegis is not a license to stop reading the UI. The best use pattern is two-step: read the page, then ask Aegis about the decision you need to make on that page. When people skip the first step, prompts get vague. When they include the page context, the resulting guidance is dramatically better.

Guided Onboarding Flow

Guided onboarding exists to transform early uncertainty into concrete structure. A first-time user often knows they want an audit-ready deliverable but does not yet know which route, which lens, or which scope details matter most. Guided onboarding shortens that path by recommending the Universal baseline, prompting for the right kinds of inputs, and moving the user toward a first draft instead of leaving them with only conceptual advice.

The flow works best when the user gives it a real deployment summary and a real operating context. The product does not need a legal memo. It does need enough context to distinguish an internal productivity assistant from a regulated workflow, a consumer-facing model, or a jurisdiction-specific deployment. Guided onboarding is therefore less about “teaching the user the app” and more about teaching the user how to describe their own situation clearly enough for the app to help.

Guided Onboarding Path to Draft Creation

The most valuable moment in onboarding is the turn from explanation to output. Until that point, the user may still be evaluating. Once guided onboarding points the user toward draft creation, the product has moved into working mode. This is why the onboarding path repeatedly returns to a few disciplines: start with Universal, describe the deployment clearly, add only the overlays you truly need, and understand that Draft is the first planned state.

If creation is blocked, treat the gate text as part of onboarding, not as an interruption to onboarding. In real use, the platform may block creation because the account is exploratory, because the user expects a capability that belongs to a different plan, or because a later export step is not yet available in the current state. Onboarding is successful when the user understands that difference and knows how to continue.

Step-by-Step Walkthrough

Open the Aegis widget from a route that already tells the product something useful about your state, ideally /dashboard or /start-here.
Start with a prompt that asks for route-aware help rather than abstract theory.
Read the response for the suggested route, baseline lens recommendation, and whether Aegis is steering you toward trial activation, paid activation, or direct creation.
If guided onboarding offers the Universal baseline, treat that as the default unless you already know a jurisdiction overlay is mandatory.
Move from Aegis into the linked surface and keep the original page context in mind as you proceed.
If a gate appears, read the exact wording before trying another route. Often the route is correct but the account state is not yet ready for the requested action.
After creation, return to Aegis if you need help interpreting Draft, Final, or export readiness.

The most important principle in this walkthrough is continuity. Aegis is most useful when it remains tied to the same decision across multiple surfaces. For example, asking for help on the dashboard, moving into billing, activating a trial, then returning to ask what has changed is much more productive than opening disconnected prompts on every page.

Explorer, Trial, and Paid Aegis Behavior

Explorers do not need to be shamed or stonewalled. In the current product, they receive a polished invitation response that explains that live Aegis guidance activates with an active trial or paid membership. This keeps the experience commercially coherent while preventing live paid guidance from being consumed by non-entitled usage.

Trial users and paid users are the live-guidance paths. If the widget shows a live path state and route-aware help is available, the product is confirming that the account is currently entitled for that class of assistance. Trial users should still remember that live Aegis does not erase trial export limits; guidance and export entitlements are related but not identical. Paid users get the broader plan capability set described on the billing page.

Typical public-facing Aegis path labels:
PATH: llm_live
PATH: llm_fallback

Typical companion language:
Governance window mode: Windowed
LLM managed

Aegis Membership and Live Guidance

The cleanest public way to think about live guidance is this: if you have activated a trial or a paid membership, the product can provide live Aegis guidance for your route-aware work. If you have not, the product will still explain how to activate that experience. This matters because Aegis is not merely decorative. It helps users through onboarding, billing interpretation, first deliverable support, export readiness questions, and route-specific decisions.

Live Aegis is available to active trial users.
Live Aegis is available to active paid users.
Explorer and otherwise non-entitled states receive a polished invitation path rather than a raw error.
The invitation path is part of the product, not a broken state.

How to Read Aegis Responses Well

A good Aegis response normally gives you four things: an interpretation of your current state, a recommendation for the next route or action, a warning if a gate still exists, and a clear suggestion of what question to ask next if you need to keep going. When any of those are missing, clarify with a route-specific follow-up. For example, instead of asking “What should I do?” ask “What should I do on the billing page if my trial is active but PDF download is still locked?”

The best follow-ups are narrow, current, and state-aware. They mention the route, the visible label, and the outcome you need. That keeps Aegis aligned with the same explanatory discipline the rest of the product uses.

How Aegis Uses Route Context

The most important fact about Aegis is that it is not answering in a vacuum. The route you are on changes what kind of answer is useful. On the dashboard, Aegis is usually interpreting working posture and next-step readiness. On billing, it is usually clarifying entitlement, trial status, and what a plan change would actually affect. On deliverables, it is more likely to explain Draft versus Final, export readiness, or how to review the artifact in front of you.

This route sensitivity is what makes Aegis more valuable than a generic assistant. It is also why vague prompting feels weak. If you ask a route-blind question from a route-rich page, you are discarding some of the best context the system has. A practical habit is to include the route or visible label directly in the prompt: “I am on the deliverables page and the artifact is still Draft. What should I do next?” That gives Aegis a clear interpretive job rather than a broad invitation to speculate.

What Live Guidance Does and Does Not Change

Live Aegis is powerful, but it does not erase every other truth in the product. It does not make a Draft suddenly Final. It does not turn a trial account into a paid distribution plan. It does not replace the billing page as the owner of commercial truth or the account page as the owner of security-sensitive actions. What it does is help you understand those truths in the moment and move to the right next action with less confusion.

This distinction matters because users sometimes over-read “live guidance” as “live override.” That is not how the product is designed. Aegis helps with interpretation, prioritization, and route sequencing. The underlying states still come from the surfaces that own them. When users understand that boundary, Aegis becomes much more trustworthy because it stops feeling like a magical black box and starts feeling like a disciplined guide.

Prompt Patterns by Route

Different routes invite different kinds of prompts.

On /dashboard, ask which route should come next, what your current plan state implies, or whether you are ready to create your first deliverable.
On /start-here, ask what minimum information you should gather before creation or whether Universal alone is a defensible starting lens.
On /billing, ask what the current state unlocks, what remains gated during trial, or what would change after activation or upgrade.
On /deliverables, ask what the current artifact state means, which sections deserve the first review pass, or what has to become true before export or sharing makes sense.
On /account, ask what a security or data-rights label means, whether a re-auth request is expected, or what evidence to capture before escalating a sensitive-account issue.

The pattern running through all of these prompts is specificity. Good prompts mention the route, the visible state, and the concrete outcome you need. That is what turns Aegis from a generic explainer into a reliable workflow assistant.

High-Value Prompts for Real Work

Explain my current account state from this page.
Should I start with Universal only, or do I need overlays?
What does Draft mean here, and what should I do while I wait for Final?
Why is this export locked, and what would unlock it?
What is the safest first deliverable path for this deployment description?
Compare trial versus paid behavior for the task I’m trying to complete.
What should I ask my internal reviewers after generating this draft?

When to Stop Prompting and Start Acting

One of the signs of a mature workflow is knowing when guidance has done its job. If Aegis has already told you which route owns the truth, what the visible state means, and what next action is appropriate, the right move is usually to act rather than keep requesting paraphrases of the same answer. Repetitive prompting often feels productive in the moment, but it can delay real progress and blur the distinction between interpretation and execution.

The cleanest stopping rule is this: if the answer has already clarified route, state, and next step, move to the route and verify the state there. If the answer surfaced a genuine mismatch, capture the exact wording and escalate with evidence. If the answer exposed missing business context, gather that context and return with a sharper question. In each case, Aegis helps best when it moves the work forward instead of becoming the work itself.

When Aegis Defers to Other Surfaces

One sign of a healthy product is that guidance does not pretend to be the only surface that matters. Aegis often points back to billing for entitlement truth, to deliverables for output truth, to account for security or data-rights operations, and to the manual for stable references. That is intentional. Aegis is an interpreter and guide, not an isolated control tower.

When Aegis redirects you to another route, treat that as productive. It means the product is preserving authoritative boundaries. Billing explains billing. Account explains sensitive account operations. Deliverables explains deliverable state. The manual explains how to understand those routes together.

Recovering from Interrupted Onboarding

Interrupted onboarding is common and rarely fatal. The fastest recovery pattern is to return to the dashboard, confirm the current plan or trial state, inspect whether any draft already exists, and then ask Aegis for the next safe step from that exact position. Do not start over automatically. First confirm what the system already knows, because the interruption may have happened after a meaningful state change.

When Aegis and the Product Seem to Disagree

If Aegis says one thing and a route seems to say another, do not immediately assume the assistant is wrong or the route is broken. First ask which surface owns the truth you care about. Billing owns entitlement. Deliverables own artifact readiness. Account owns sensitive identity and rights actions. Aegis may be accurately describing the implication of a state while the user is expecting a different class of answer from the page.

When a real mismatch remains after that check, the best escalation packet is compact: route, visible wording, current commercial posture as you understand it, timestamp, and the shortest reproduction sequence. Aegis can even help you prepare that packet. That is a healthier use of guidance than asking it to argue with the product’s visible state.

Appropriate Use and Responsible Expectations

Aegis is excellent at making the product legible. It is not meant to flatten every governance question into a one-line answer. Some decisions still require internal policy owners, legal review, or cross-functional alignment. Use Aegis to surface the question clearly, identify the next route or artifact, and keep the work moving without inventing certainty where certainty does not exist.