Automated
Intake.

One client gets one stable Journey Board. The client does not receive a pile of unrelated forms, documents, or slugs. Under the interface, every response, stage, receipt, and revision remains immutable and independently auditable.

The stable Journey Board URL is the intended client destination, not an automatic cutover. Existing CRM and partnership-progress surfaces remain in place until the board passes its own production-readiness review and a separate human go-live decision makes it the client home.

Client portal destination

Every client will have one authenticated Ventari portal for their agreements, decision rooms, approved deliverables, launch status, and ongoing delivery.

The portal organizes authoritative records; it does not create duplicate copies. Drafts and internal working documents remain hidden, while signatures, approvals, and receipts remain governed by their owning systems.

For Rising Origin, this is approved product direction but is not live yet. The portal exists for intake, onboarding and automated client communications. It does not give the client access to their CRM. The CRM keeps its own login, and the portal can link to it once that is built. The portal goes live for a client only after production review and Ventari's approval.

1. 1Company and authority
2. 2Goals and engagement scope
3. 3Customers, offers, and revenue path
4. 4Brand, content, and proof
5. 5Sales, intake, and fulfillment
6. 6Team and operating rules
7. 7Existing systems, data, and migration
8. 8Connections
9. 9Module-specific build decisions
10. 10Review, launch, and cutover
11. 11Continuous delivery

The board autosaves drafts, advances a stage only when its server-owned completion rules pass, and shows the client what completion unlocks next. After launch, the finite setup counter becomes an ongoing delivery view rather than claiming that the relationship is finished.

Five client-facing launch stages

The client experience groups the journey into five plain-language stages:

1. 1Alignment — agree on the audience, offer, first test, measurement, form and booking proof, and launch-copy direction.
2. 2Access & connections — collect the accounts, invitations, authorizations, and verified provider connections needed for delivery.
3. 3Build & configure — prepare the selected CRM, website, marketing, reporting, and fulfillment modules.
4. 4Test & approve — prove the configured paths, review exact public claims and creative, and collect the approvals required for launch.
5. 5Launch & measure — make separately approved production changes, monitor the live system, reconcile results, and move into ongoing delivery.

These five stages are the client's navigation and progress model. The eleven journey domains above are the canonical requirements model underneath them. A requirement may be collected once in one domain and projected into whichever launch stage needs it. The two structures must not compete in the interface or create duplicate questions. The eleven domains are never shown to the client as a list and never emitted as their own questions. They are projected silently into the five stages. A generator that renders the domain list, or asks a client to answer a domain it has already answered inside a stage, has failed and the golden run fails with it.

When a Journey Board is generated, the worker creates all five stage shells and the complete set of requirements currently known from the approved template, selected modules, CRM identity, and allowlisted Client Brain facts. The worker may map and phrase approved requirements; it may not invent a new permission request, public claim, budget, launch act, provider access request, or cutover authority.

Live stage directory

The Journey Board is also the client's complete onboarding directory. Every one of the five launch stages is selectable from the same stable URL from the moment the room is created. The active stage is visually prominent, completed stages retain their approved outcomes, and later stages open as useful previews rather than remaining hidden.

Access is gated at the item level, not by hiding or disabling an entire later stage:

• A client may answer or submit any item in any stage when that item's server-owned state is Ready for you and it has no unresolved blocker.
• A blocked item remains visible and names the blocker, its owner, the exact unlock condition, and what will happen next. Its response control remains disabled.
• One stage may contain a mix of Complete, Ready for you, Ventari is working, Waiting on access or evidence, Coming later, Review needed, and Not applicable items.
• Opening a stage does not activate it, create a commitment, or grant execution authority.
• Answering an item does not complete its stage. A stage completes only when every required receipt, provider verification, dependency, and human gate declared by the server is satisfied.
• Approving an item records evidence. It does not spend, publish, launch, migrate, change permissions, or switch a public form unless a separate production approval explicitly grants that act.

A previewed owner, date, budget, dependency, or task is planning context, not a commitment, until its required human confirmation exists. Browseable does not mean answerable; answerable does not mean complete; complete does not mean executed.

The stage directory is a projection, not a second task system. VentariFullApp remains authoritative for task state, connection state, module readiness, and stage completion. The Decision/Journey application renders the client-safe projection and records client responses.

Worker generation contract

The room generator emits a versioned definition for every known stage item with, at minimum, a stable stage key, stable item key, client-safe title and explanation, state, owner, authority class, required evidence, blocker keys, unlock condition, module consumers, and executionAuthority: false unless a separately reviewed production contract says otherwise.

New approved Brain context may fill an empty allowlisted informational item, add a newly relevant requirement, or reopen one affected dependency. It may never silently rewrite a submitted answer. Newly projected work must appear inside the existing five-stage board rather than creating another form, slug, or client dashboard.

Automated Intake uses the CRM's existing canonical identity spine. It does not create a second contact system, accept identity authority from the browser, or collapse three different records into one:

• the operating client is the relationship Ventari works;
• the business is an optional CRM organizations record; and
• the account is a person and, when applicable, a login attached through the existing people, profile, email, relationship, and membership records.

All three relationships already allowed by W19 remain valid: a client may exist before a business is attached, one client may own several businesses, and several people may belong to one business. Intake resolves tenant_id, source identity, client relationship, person, and organization on the server.

The intake bridge must call the existing canonical resolver in lib/client-lifecycle/canonical-identity.ts rather than implement new matching rules. Exact verified email, an existing provider identity, and a unique promotable business domain are the only automatic identity evidence. Display names are labels, never join keys. An exact match links the submission to the existing record. A new exact identity may create or promote the existing provisional person and business through the same resolver. Duplicate email, shared inbox, domain collision, conflicting provider identity, name-only evidence, or any other ambiguity creates an identity review case and stops projection.

The browser may submit answers and a signed room/session reference. It may not choose tenant_id, client_key, person_id, organization_id, Client Program, or Client Brain authority. Those are resolved from the authenticated or signed server context. No answer may reach module setup, CRM tasks, Client Brain promotion, or delivery automation until identity resolution returns one bounded client context.

The Connections stage is generated from earlier answers and selected modules. It uses one consistent client experience while supporting provider-specific mechanisms:

• OAuth authorization;
• provider app installation;
• account or team invitation;
• encrypted credential entry, which happens inside the CRM's own connection flow and never in the Journey Board itself;
• an existing access confirmation, where Ventari already holds the connection and the client only confirms it;
• DNS proof and verification;
• manual evidence when no safe automation exists.

The Journey Board never asks a client for a password, API key, token, or other secret, and tells clients not to enter one. Free-text answers are screened for common credential patterns (bearer tokens, private-key blocks, password: style assignments, and similar). That screen is a mitigation and cannot recognize every secret, in particular an arbitrary bare password typed into free text. The typed-secret route is the guarded path for any real credential handoff. The board offers OAuth, provider app installation, account or team invitation, DNS proof, an existing-access confirmation, and manual evidence. Where a provider genuinely requires a key, the client enters it in the owning CRM's connection flow, not here. The Decision/Journey application screens free text before storage; that screen is not a guarantee that no plaintext secret was stored. A short-lived, signed, tenant-bound install session opens the exact CRM connection flow. The CRM owns instance_connections, encrypted tokens, provider identities, scopes, refresh state, verification, and disconnect behavior.

A card is Connected only after a provider read proves the selected identity and required scope. The existence of a database row or an OAuth callback is insufficient.

Access & connections is one generated checklist, not a pile of forms and not a manual stage switch. It is the client-facing interface between Intake, Connections, and the computed journey.

The factory model is:

Plan and selected modules → required access manifest → hide irrelevant items → client action → verification evidence → computed stage

The manifest is generated from, in order:

1. 1The client's purchased modules and published delivery plan.
2. 2The tenant pack's required integrations.
3. 3Connections already verified in the CRM.
4. 4Conditional client answers such as "we use this" or "not applicable."
5. 5Explicit staff overrides with a recorded reason.

Only outstanding items dominate the page. Verified items live in a collapsed Already connected section so the proof remains accessible. Systems such as Vercel, GitHub, Supabase, GA4, and Search Console appear only when the selected work actually requires a client action. An already-verified connection is never presented as new homework.

Client actions

The client may:

• say whether a conditional system applies;
• complete an OAuth, invitation, upload, or secure-access action in the owning CRM connection flow;
• mark I completed this, which creates labeled evidence;
• see whether Ventari has verified it.

A client checkbox alone must not make access Connected. Brain accessibility does not equal permission to launch, spend, publish, or change access.

Client display states

Stage completion still uses server-owned required evidence. Optional extra context never blocks Access & connections. A staff conversation may satisfy Alignment evidence; it does not skip required access verification.

Rising Origin campaign configuration

This is a configuration example of the same standard, not a second checklist product. Rising Origin remains Active / ramping. Alignment is not the blocker. Nick does not receive another Alignment room. Ventari first audits what it and Edgar already possess, then sends Nick one consolidated request for only the missing access or assets.

CAPI, when prepared, is Lead and Schedule only, using hashed contact details the lead supplied. Messages, notes, and CRM contents are excluded. CAPI is not activated until Meta identity and the live message path are verified. Paid spend requires its own later yes.

Draft saving and client submission are different events. The approved target contract is item-level submission: every decision and every fact is submitted independently.

• Autosave protects unfinished work.
• Each decision and fact has its own explicit Submit action.
• Submit creates an immutable item receipt with actor, client, room, stable item key, item-definition checksum, response revision, timestamp, prior receipt when revised, and idempotency key.
• Editing a submitted answer requires Revise answer, creates a new item revision, and visibly reopens only that item plus explicitly declared downstream dependencies.
• A stage completes only after every required submission and provider verification passes.

The same contract applies to Ventari founder decision rooms, client decision rooms, onboarding, deliverable approvals, change requests, and ongoing delivery forms. Copy may vary; evidence semantics do not.

For the shared Decision Room renderer, one room is one guided review containing independently submittable items. Individual cards autosave draft work, then lock only after their own Submit action. Revise answer reopens one item while preserving its receipt lineage. Room completion is derived from current required item receipts; it is not a second submission event. Submission coverage and business resolution remain separate so a fully answered room may still need review.

Receipt ids, checksums, projections, locks, definition changes, store modes, and revision lineage are implementation evidence, not client copy. The client sees plain outcomes: Answer saved, Submit answer, Submitted, Revise answer, Ready to edit, Wording updated, and Ventari will follow up. Technical evidence stays in the durable record and staff verification surfaces. When every answer is submitted but one or more answers need follow-up, the room says Answers submitted, not Review complete.

The approved detailed design is 04-ITEM-LEVEL-SUBMISSION-DESIGN.md. The earlier whole-room receipt implementation remains evidence of the draft-versus-submit principle, but it is not the production target.

The team-review deployment remains read-only. A real submission surface requires a durable response store and an approved access model. A direct-link room may remain trust-attributed and nonbinding only when the owner accepts that anyone holding the link could impersonate a participant. Authenticated portal identity or a signed, tenant-bound link is required before a submission may be treated as verified client identity.

Repository and production-storage gate

The existing private joyblisscoder/client-agreements repository is the leading candidate for the shared Decision Room application, client-facing GitHub assets, response history, and immutable submission receipts. The repository already contains the shared renderer and a signatures branch used as a durable response ledger. It is not currently organized as one complete folder per client, and the Rising Origin Cloudflare Worker has no production response credential.

The proposed per-client repository organization is a pending production-lane decision, not a landed standard. The next production wave must first inventory every current agreement, decision room, response path, receipt path, and consumer; define a backward-compatible client key and folder contract; and prove that existing links and historical receipts remain readable. Client folders may contain versioned room definitions, approved client-facing assets, submission receipts, and manifests. They must never contain provider tokens, passwords, plaintext secrets, or a duplicate Client Brain.

If this repository becomes the production store, the Worker receives only a fine-grained GitHub credential restricted to joyblisscoder/client-agreements with the minimum repository Contents read/write permission required by the proven path. Broad personal or workflow-enabled tokens are not accepted as the production default. The credential stays in the hosting provider's secret store and is never written to source, a client folder, a rendered page, a receipt, or the Brain.

Production enablement remains held until the lane proves all of the following:

1. 1one canonical per-client folder contract and compatibility plan;
2. 2tenant/client isolation and server-owned identity resolution;
3. 3durable draft, submission, receipt, and revision reads and writes;
4. 4authenticated portal identity or a reviewed signed-link model;
5. 5deterministic projection into the CRM and Client Brain, with conflicts held for review;
6. 6credential rotation, recovery, and least-privilege verification; and
7. 7a Rising Origin golden run followed by a second-client configuration run.

Until those gates pass, the team-review Worker stays read-only even though the shared interface can render Approve, Change, Question, Submit, and Revise controls.

The original response remains the source record. Clearly mapped answers automatically project into the correct client authority. Conflicts, ambiguous free text, questions, requested changes, secrets, sensitive material, and disagreement with newer canonical facts stop for review.

The Journey Board must re-project when the owner-qualified Client Brain gains newer approved context. Auto-fill is an explicit field allowlist, never a model judgment. Deterministic, informational requirements may be prefilled or completed automatically only when the fact is current, cited, identity-bound, already approved, mapped to a named field, satisfies the requirement's declared authority and comparison rule, and carries executionAuthority: false. The resulting board item names the source and time of the update in staff evidence while using plain client-facing language. Anything outside the allowlist stops for staff review.

Brain context never silently rewrites an immutable client submission. Permission, public claims, provider access, spend, scope changes, publication, launch, migration, and cutover always require the appropriate explicit human approval. If newer Brain context conflicts with a submitted answer or changes what an approval would mean, preserve the existing receipt, mark only the affected item Review needed, show the client what changed, and require a new revision before that dependency can complete.

The staff review surface is Ventari Command Center. Clients see only Review needed and a plain explanation of what changed; they never enter the internal ambiguity surface. GitHub remains the durable publication ledger. Approved Brain projections retain citations to the original response and receipt.

Agents may:

• read approved, cited client context;
• create work from approved templates;
• propose structured decision cards;
• continue after a verified client response;
• record generalized lessons after review.

Custom client-facing questions proposed by an agent require Ventari review before publication. Raw private client submissions never enter the CRM Factory skill or operating Brain as generalized learning.

ICM submission movement

The response record is evidence, not execution authority. Submission produces a versioned source receipt and a bounded projection event with stable decision and fact keys. Ventari resolves tenant, organization, Client Program, and Client Brain identities server-side; the browser never supplies those authorities.

• Preserve the original submitted response once, with its checksum and receipt.
• Promote a clearly mapped fact only when its authority and comparison rule are deterministic and it does not conflict with a newer or higher-authority fact.
• Send conflicting, ambiguous, sensitive, free-form, or low-confidence material to review.
• Treat Approve, Change, and Question as client-review evidence. They may propose scope, tasks, or follow-up; they do not grant production release, provider access, spend, migration, or publication authority.
• Keep planned, built, tested, released, delivered, and client-accepted as separate evidence states.

• Decision/Journey app: client-facing interface, draft state, immutable response and submission records.
• VentariFullApp: client identity, membership, connection state, module completeness, tasks, approvals, work, and receipts.
• Client Brain: screened durable client facts, preferences, decisions, approved strategy, and indexed artifacts.
• CRM Factory specification: module contract, templates, installation rules, verification, and generalized lessons.
• GitHub: the immutable receipt and publication ledger for the agreements application. It stores what was submitted and when; it is not the record of what is true or what is ready. Agents read projections, never the raw Git branch, and Git receipts are never the only long-term source of truth.
• Provider: account identity and live connection truth.

The client's Journey Board is Ventari. Suzuki Systems, CRM Factory, phase numbers, receipt ids, checksums, and internal lane vocabulary are delivery-side language and must never appear in a client workspace. They remain correct on internal specification pages such as this one.

Every active client stage names two distinct accountable seats when applicable: the client final approver and the internal Ventari delivery owner. Naming the client approver never removes the internal delivery owner's responsibility for staff work.

Current reference state — 2026-09-26

Rising Origin remains Active / ramping. Alignment is not the current blocker. Staff recorded alignment as human-sourced evidence. That is not a Nick receipt and does not authorize a Brain vault write, a merge, or a deployment. Nick does not receive another Alignment questionnaire. Proof collection remains in Access & connections. Exact public claims remain in Test & approve. Paid spend remains a separate launch gate.

Updated 2026-09-29: the shared native Project Request capability is merged. Rising Origin's instance-owned Project Request form is published (Publication 2) but cannot yet accept a native submission, because the attempt-signing secret is not configured, and no native submission has been received. The controlled synthetic proof (Packet A) is parked. That proof is Access & connections work; it does not complete, verify, or advance an Access checklist item. GoHighLevel remains the public project-request and booking route until a separately approved cutover. ChatbotBuilder waits on Edgar's workspace access, and its nurture email is not configured.

The golden run now runs through the Client Portal, where the client views their agreements and documents and moves through the client journey. The earlier five-card Alignment room is superseded as the live client destination. Approvals in Alignment, when they exist, authorize preparation only; they do not start spend, publish ads, or switch the public form.

One non-blocking cleanup item remains recorded. The Card 4 disclosure was renamed from View the cutover proof checklist to View the proof checklist on 2026-09-25 (PR #31), because the card states it does not authorize the cutover and the word did not belong in the label above it. Still open: ensure a one-person room never renders or briefly flashes Hidden until everyone finishes. Neither residue creates authority, changes a receipt, or blocks the verified room when the live client view does not display it.

Use existing verified Brain facts as Confirm or edit prefills. The pilot must cover:

• organization and approval identity;
• audience, offer, CTA, geography, and public proof. Not the guarantee: Alignment already kept the published 24-hour standard and parked service-day credit and concurrency as proposals, so the board must not prefill or re-ask a guarantee the client has already settled;
• lead-response owner and response standard;
• website, booking, intake, CRM, and GoHighLevel cutover state;
• Vercel, GitHub, Supabase, Search Console, GA4, Meta, X, Resend, calendar, and any confirmed payment connection;
• CRM pipeline, users, automation rules, reporting, migration, and rollback;
• launch tests, client approval, and a seven-day reconciliation window where applicable.

The golden run must prove at least:

1. 1one mapped answer auto-promotes;
2. 2one answer creates a CRM task, and creating that task performs none of it — the same fence as Command Center. The task is queued work for a named owner, not an executed action;
3. 3one conflicting answer enters Command Center review;
4. 4one provider connection completes after a real read;
5. 5one provider failure stays visibly unresolved;
6. 6one explicit submission creates a receipt;
7. 7one edit after submission creates a new revision and reopens the correct requirement;
8. 8every action remains scoped to Rising Origin;
9. 9the client sees one continuous board;
10. 10a cold agent can resume from the evidence without asking what happened.
11. 11one newer approved Brain fact re-projects the board and resolves an eligible informational requirement without rewriting any client receipt;
12. 12one conflicting Brain fact reopens only the affected dependency for review and leaves unrelated stages unchanged.
13. 13all five launch stages exist from the first render and can be opened from the stable URL;
14. 14one unblocked item in a later stage can be answered before the preceding stage is complete;
15. 15one blocked item remains visible, explains its blocker and unlock condition, and cannot be submitted;
16. 16stage completion is derived from server-owned requirements rather than which stage the client last opened;
17. 17a one-person room never renders or flashes multi-participant completion language; and
18. 18submission mechanics are proved with a Ventari-controlled test identity before Nick is asked to submit anything. No fake Nick answer may be used as test data.
19. 19the client view never renders the eleven journey domains as a list or as their own questions; every requirement reaches the client inside one of the five stages; and
20. 20no approved item performs the act it approves. Approval creates evidence and may queue work for a named owner; spend, publication, migration, permission change, and public-path switching each require their own later confirmation.

• Stable authenticated URL per client.
• Five client-facing launch stages are always available as navigation; the eleven journey domains remain the underlying requirements model.
• One active stage is prominent without becoming the only answerable stage; completed stages collapse with receipts; later stages explain what they require.
• Gate individual items. Any item marked Ready for you may be answered wherever it appears; blocked items remain visible with a plain-language reason and unlock condition.
• Show completed requirements rather than a fabricated percentage when the denominator can change.
• Use restrained progress animation, clear completion states, and “what this unlocks next.”
• Preserve the current premium Ventari visual language and the CRM Factory contrast, spacing, light/dark card hierarchy, motion restraint, and mobile wrapping decisions.
• Mobile is verified at 390 px.
• No decorative animation may obscure copy, controls, focus state, or reduced-motion preferences.
• Speak directly to the client as you/your. Do not narrate the client or its owner in the third person inside their own workspace.
• Prefer the client's business language over internal delivery language. Explain necessary provider terms once; do not expose code names, storage terms, receipt ids, or agent vocabulary.
• A one-person room never shows multi-participant waiting language in initial HTML, first paint, or hydrated state.
• A client critique changes both the current deliverable and this reusable standard when it reveals a general rule. Preserve the critique and reorientation in the lane report instead of leaving the learning only in chat.