7DEA

Chapter 09

Open the AppBack to Docs Home

Chapter 09: Route Reference and Page Playbooks

This chapter is for users who think best in pages rather than in abstract concepts. If you know the route you are on but not what the route expects from you, these playbooks give you a practical reading order and a set of route-specific habits.

Public Home and Marketing Pages

/ should be read as a purpose-built surface inside the larger governance workflow. This is the evaluation and conversion layer where readers understand what 7DEA is, what it promises, and where the app begins. The route matters because it tells you what category of truth you are supposed to read there: onboarding truth, billing truth, deliverable truth, or account-security truth. Users save time when they let the route define the question instead of carrying assumptions from an earlier page into the current one.

A strong read of / starts with the heading and supporting copy, then the visible state language, then the primary action area. Read the promise, the navigation, and the calls to action as a staged invitation: learn, compare, then open the app when you are ready to work account-first. That pattern prevents the most common navigation error in 7DEA, which is treating every route as if it were a generic dashboard when in reality each page is trying to help with a different class of decision.

Best reasons to use /

  • Understanding whether the product addresses your workflow at all.
  • Comparing public explanations before deciding to sign in or activate a trial.
  • Finding the docs route or lens catalog without entering the full app workflow immediately.

Signals that matter most here

  • Docs links indicate a stable manual anchor exists for the topic.
  • Open the App calls to action indicate the place where account-scoped truth begins.
  • Plan or trust messaging here is orientation material, not a replacement for billing truth.

Mistakes to avoid on /

  • Assuming the public site is the same thing as the account-scoped dashboard.
  • Treating marketing copy as though it should answer route-specific troubleshooting questions.
  • Trying to infer plan readiness from public copy instead of the billing route.

Move into /docs, /lens-catalog, /auth, or /billing depending on whether your next need is learning, selecting a governance frame, signing in, or activating access. When the route is working properly, it should reduce ambiguity rather than create it. If you leave the route more confused than when you arrived, the manual or context-help anchor linked from that route is usually the right corrective step.

Authentication Surface

/auth and /auth/verify should be read as a purpose-built surface inside the larger governance workflow. These routes turn a public visitor into a known account holder through the email OTP flow. The route matters because it tells you what category of truth you are supposed to read there: onboarding truth, billing truth, deliverable truth, or account-security truth. Users save time when they let the route define the question instead of carrying assumptions from an earlier page into the current one.

A strong read of /auth and /auth/verify starts with the heading and supporting copy, then the visible state language, then the primary action area. Read the sign-in or verification instructions before re-requesting codes, because most issues at this stage come from sequencing rather than from product failure. That pattern prevents the most common navigation error in 7DEA, which is treating every route as if it were a generic dashboard when in reality each page is trying to help with a different class of decision.

Best reasons to use /auth and /auth/verify

  • Starting a new account-scoped session.
  • Returning after sign-out or session expiration.
  • Beginning the transition from explorer behavior to trial or paid behavior.

Signals that matter most here

  • OTP language indicates the product is still proving identity, not yet proving entitlement.
  • Post-auth redirects or billing prompts tell you what the product thinks should happen next.

Mistakes to avoid on /auth and /auth/verify

  • Confusing successful sign-in with paid entitlement.
  • Leaving the auth flow before verification completes and then assuming downstream routes are broken.

After verification, go to dashboard or billing depending on whether your next need is route-aware guidance or commercial activation. When the route is working properly, it should reduce ambiguity rather than create it. If you leave the route more confused than when you arrived, the manual or context-help anchor linked from that route is usually the right corrective step.

Start Here

/start-here should be read as a purpose-built surface inside the larger governance workflow. This route compresses the first deliverable story into a practical runway with links into the app. The route matters because it tells you what category of truth you are supposed to read there: onboarding truth, billing truth, deliverable truth, or account-security truth. Users save time when they let the route define the question instead of carrying assumptions from an earlier page into the current one.

A strong read of /start-here starts with the heading and supporting copy, then the visible state language, then the primary action area. Read the fast path checklist, the trust bar, and the Draft-to-Final explanation before deciding whether to create work immediately. That pattern prevents the most common navigation error in 7DEA, which is treating every route as if it were a generic dashboard when in reality each page is trying to help with a different class of decision.

Best reasons to use /start-here

  • Orienting a new teammate without sending them through every route.
  • Confirming the shortest safe sequence from sign-in to first deliverable.
  • Understanding trial expectations before you touch exports.

Signals that matter most here

  • Checklist order tells you which prerequisite the product believes comes next.
  • Draft-to-Final copy explains why immediate generation and later publication can coexist.

Mistakes to avoid on /start-here

  • Treating Start Here as though it should contain every advanced reference detail.
  • Skipping the linked routes and expecting the summary page itself to perform every action.

Leave Start Here for dashboard, billing, lens catalog, or deliverable creation as soon as the next route is clear. When the route is working properly, it should reduce ambiguity rather than create it. If you leave the route more confused than when you arrived, the manual or context-help anchor linked from that route is usually the right corrective step.

Dashboard

/dashboard should be read as a purpose-built surface inside the larger governance workflow. Dashboard is the command surface that best reveals current commercial truth, next actions, and recent output posture. The route matters because it tells you what category of truth you are supposed to read there: onboarding truth, billing truth, deliverable truth, or account-security truth. Users save time when they let the route define the question instead of carrying assumptions from an earlier page into the current one.

A strong read of /dashboard starts with the heading and supporting copy, then the visible state language, then the primary action area. Read the subscription summary, trust bar, next-step card, and checklist before opening any deeper surface. That pattern prevents the most common navigation error in 7DEA, which is treating every route as if it were a generic dashboard when in reality each page is trying to help with a different class of decision.

Best reasons to use /dashboard

  • Confirming whether the account is active trial, active paid, or otherwise limited.
  • Choosing the next route without relying on memory.
  • Returning after plan changes, trial activation, or a confusing interrupted session.

Signals that matter most here

  • Subscription summaries explain what the product currently believes your commercial state is.
  • The checklist tells you whether plan choice, first draft creation, or export readiness is the real next milestone.

Mistakes to avoid on /dashboard

  • Ignoring the dashboard because it looks too simple.
  • Opening exports or billing blind without first checking what the dashboard already knows.

Use the dashboard as the central hub whenever you need to re-anchor yourself in current state before making a more specific move. When the route is working properly, it should reduce ambiguity rather than create it. If you leave the route more confused than when you arrived, the manual or context-help anchor linked from that route is usually the right corrective step.

Lens Catalog

/lens-catalog should be read as a purpose-built surface inside the larger governance workflow. The lens catalog is the public learning and selection surface for baseline and overlay strategy. The route matters because it tells you what category of truth you are supposed to read there: onboarding truth, billing truth, deliverable truth, or account-security truth. Users save time when they let the route define the question instead of carrying assumptions from an earlier page into the current one.

A strong read of /lens-catalog starts with the heading and supporting copy, then the visible state language, then the primary action area. Read the lens description, status label, plan badges, and signal language in that order. That pattern prevents the most common navigation error in 7DEA, which is treating every route as if it were a generic dashboard when in reality each page is trying to help with a different class of decision.

Best reasons to use /lens-catalog

  • Choosing whether Universal alone is enough.
  • Understanding which overlays are genuinely relevant to the deployment.
  • Comparing stable and status-tracked governance frames before execution.

Signals that matter most here

  • Plan badges show commercial posture for operational use.
  • Signal-sync and status labels show freshness and stability posture.

Mistakes to avoid on /lens-catalog

  • Adding overlays for prestige instead of relevance.
  • Confusing public browse availability with execution entitlement.

Move to deliverable creation once you can justify your baseline and overlay choices in plain language. When the route is working properly, it should reduce ambiguity rather than create it. If you leave the route more confused than when you arrived, the manual or context-help anchor linked from that route is usually the right corrective step.

New Deliverable

/deliverables/new should be read as a purpose-built surface inside the larger governance workflow. This route turns your scope and lens choice into the first structured artifact. The route matters because it tells you what category of truth you are supposed to read there: onboarding truth, billing truth, deliverable truth, or account-security truth. Users save time when they let the route define the question instead of carrying assumptions from an earlier page into the current one.

A strong read of /deliverables/new starts with the heading and supporting copy, then the visible state language, then the primary action area. Read the creation prompt and confirm that the scope statement is concrete enough to deserve a real draft. That pattern prevents the most common navigation error in 7DEA, which is treating every route as if it were a generic dashboard when in reality each page is trying to help with a different class of decision.

Best reasons to use /deliverables/new

  • Creating a first draft from a clearly described deployment.
  • Testing how a chosen lens posture changes the resulting structure.

Signals that matter most here

  • Field wording tells you the system wants deployment facts, not vague mission statements.
  • Creation success should be followed by a Draft state, not assumed export readiness.

Mistakes to avoid on /deliverables/new

  • Treating the new-deliverable route as a place to brainstorm instead of a place to submit scope.
  • Expecting a perfect final export before reviewing the first draft.

After creation, review the resulting Draft and the trust-bar context before thinking about PDF or sharing. When the route is working properly, it should reduce ambiguity rather than create it. If you leave the route more confused than when you arrived, the manual or context-help anchor linked from that route is usually the right corrective step.

Deliverables List and Detail

/deliverables and /deliverables/[id] should be read as a purpose-built surface inside the larger governance workflow. These routes show what exists, what is ready, and what still depends on state or entitlement. The route matters because it tells you what category of truth you are supposed to read there: onboarding truth, billing truth, deliverable truth, or account-security truth. Users save time when they let the route define the question instead of carrying assumptions from an earlier page into the current one.

A strong read of /deliverables and /deliverables/[id] starts with the heading and supporting copy, then the visible state language, then the primary action area. Read the state labels on the deliverable itself before focusing on buttons. That pattern prevents the most common navigation error in 7DEA, which is treating every route as if it were a generic dashboard when in reality each page is trying to help with a different class of decision.

Best reasons to use /deliverables and /deliverables/[id]

  • Checking whether a deliverable is still Draft or already Final.
  • Understanding whether PDF or share controls are legitimately ready.
  • Reviewing recent outputs without creating new work.

Signals that matter most here

  • Draft versus Final is the central readiness signal.
  • Locked or limited export controls explain whether the issue is state, plan, or trial posture.

Mistakes to avoid on /deliverables and /deliverables/[id]

  • Treating locked download as proof the deliverable failed.
  • Skipping review and going straight to distribution.

Stay here for review or distribution. Go back to creation only if the real problem is the scope or lens choice, not the current deliverable state. When the route is working properly, it should reduce ambiguity rather than create it. If you leave the route more confused than when you arrived, the manual or context-help anchor linked from that route is usually the right corrective step.

Billing

/billing and /billing/checkout should be read as a purpose-built surface inside the larger governance workflow. Billing is the commercial truth surface where plan, trial, and upgrade posture become legible. The route matters because it tells you what category of truth you are supposed to read there: onboarding truth, billing truth, deliverable truth, or account-security truth. Users save time when they let the route define the question instead of carrying assumptions from an earlier page into the current one.

A strong read of /billing and /billing/checkout starts with the heading and supporting copy, then the visible state language, then the primary action area. Read the current state, trial wording, and limitation copy before focusing on price or buttons. That pattern prevents the most common navigation error in 7DEA, which is treating every route as if it were a generic dashboard when in reality each page is trying to help with a different class of decision.

Best reasons to use /billing and /billing/checkout

  • Activating trial or paid access.
  • Understanding what a lock elsewhere in the app actually means.
  • Reviewing renewal, cancellation, or upgrade posture.

Signals that matter most here

  • Trial day copy and plan summaries explain current entitlement.
  • Limitation lists explain what is intentionally unavailable during trial.

Mistakes to avoid on /billing and /billing/checkout

  • Treating price cards as purely marketing content instead of workflow contracts.
  • Assuming a prior checkout attempt changed state without verifying the page afterward.

Return to dashboard or Aegis after a state change so the rest of the workflow can be reinterpreted in light of the new commercial posture. When the route is working properly, it should reduce ambiguity rather than create it. If you leave the route more confused than when you arrived, the manual or context-help anchor linked from that route is usually the right corrective step.

Account

/account should be read as a purpose-built surface inside the larger governance workflow. Account is the trust-management surface for sessions, sensitive actions, and data rights. The route matters because it tells you what category of truth you are supposed to read there: onboarding truth, billing truth, deliverable truth, or account-security truth. Users save time when they let the route define the question instead of carrying assumptions from an earlier page into the current one.

A strong read of /account starts with the heading and supporting copy, then the visible state language, then the primary action area. Read the section headings and token or session language before attempting sensitive actions. That pattern prevents the most common navigation error in 7DEA, which is treating every route as if it were a generic dashboard when in reality each page is trying to help with a different class of decision.

Best reasons to use /account

  • Reviewing active sessions and signing out where needed.
  • Starting data export or deletion requests.
  • Confirming what stronger verification still needs to happen.

Signals that matter most here

  • Session lists tell you whether account access is where you expect it to be.
  • Token-status or re-auth language tells you whether a sensitive action is ready or still protected.

Mistakes to avoid on /account

  • Expecting a sensitive action to behave like an ordinary preference change.
  • Ignoring audit or token information and retrying actions without reading the page.

Use account for security and rights operations, then move back into billing or workflow surfaces only after the account state is clear. When the route is working properly, it should reduce ambiguity rather than create it. If you leave the route more confused than when you arrived, the manual or context-help anchor linked from that route is usually the right corrective step.

Docs

/docs should be read as a purpose-built surface inside the larger governance workflow. The docs route is the canonical public explanation layer for the live product. The route matters because it tells you what category of truth you are supposed to read there: onboarding truth, billing truth, deliverable truth, or account-security truth. Users save time when they let the route define the question instead of carrying assumptions from an earlier page into the current one.

A strong read of /docs starts with the heading and supporting copy, then the visible state language, then the primary action area. Read the grouped table of contents and the chapter summaries before diving into the first section that looks familiar. That pattern prevents the most common navigation error in 7DEA, which is treating every route as if it were a generic dashboard when in reality each page is trying to help with a different class of decision.

Best reasons to use /docs

  • Understanding route-specific behavior without private engineering detail.
  • Finding the exact anchor linked by context help.
  • Training teammates or refreshing your own workflow memory.

Signals that matter most here

  • Chapter summaries and nested anchors show how the product expects concepts to connect.
  • Stable slugs and anchors indicate the docs are part of the live support surface, not an afterthought.

Mistakes to avoid on /docs

  • Treating the manual as a flat brochure instead of as a route-aware operating reference.
  • Skipping linked anchors and reading only the nearest top-level chapter title.

Return to the live route you were using and apply the explanation there. The manual is most valuable when paired with the current screen, not when read in isolation. When the route is working properly, it should reduce ambiguity rather than create it. If you leave the route more confused than when you arrived, the manual or context-help anchor linked from that route is usually the right corrective step.