Progressive Intake Web Page Design

Short Answer

RIFF should split intake into two coordinated channels:

phone call: enough L0 identity + intent to keep the call moving
web intake: everything hard, slow, risky, or typo-prone over voice

Current implementation: space_channel_widgets has experimental option 0, space_profile_intake, generated by the Space Channel widgets importer. The pack uses sms_verification: true, which compiles to SMS opt-in, one link+code text via intake_send_verification_link, spoken-code verification, and a short profile collection stage. The current link opens the shipped companion page; /intake.html is the next web surface.

Intake Types

Law, plumbing, and electrical are usually problem intake. Space Channel is mostly profile intake: content comes first, and the link lets the caller add email, preferences, points, and security later.

The Progressive Model

Web Page UX

The page should open in a state that makes the caller feel almost done:

We have:
  Phone: +1 ...
  Request: Space Channel alerts / legal intake / plumbing visit

[Submit this now]

Add more:
  [Email updates] [Photos/documents] [Points] [Security] [Credit]

• L0 is one screen and has the primary submit.
• Optional modules are cards or steps after L0, not a long required form.
• The caller can skip every optional module.
• Security and credit modules are handoffs, not embedded secrets collection.
• Informational flows like Space Channel emphasize content and subscriptions, not "create account."

Vertical Examples

Pack Shape

The Business Pack remains canonical. Progressive intake extends kind: intake_form with channel, requirement, and optional module metadata while keeping slots: compatible with the existing slot_types contract.

capabilities:
  - id: start_intake
    kind: intake_form
    label: Start intake
    sms_verification: true
    web_intake:
      enabled: true
      sms_offer: after_l0
      allow_partial_submit: true
      resume_ttl_hours: 72
      modules:
        contact: true
        attachments: true
        points: optional
        security: optional
        credit: hosted_handoff
    stages:
      - id: l0_identity
        tier: l0
        required: true
        channels: [voice, web]
        slots: [caller_name, callback_number, intake_intent]
      - id: contact_details
        tier: l1
        required: false
        channels: [web]
        slots: [email, preferred_contact_method, timezone]
      - id: vertical_detail
        tier: l2
        required: false
        channels: [voice, web]
        slots: [issue_description, service_address, photos]
      - id: account_modules
        tier: l3
        required: false
        channels: [web]
        slots: [points_opt_in, auth_setup_preference,
                credit_handoff_preference, notification_preferences]

The compiler emits both voice states and a web intake schema. Different verticals belong in the pack, not in custom page code.

Runtime Flow

caller dials line
  -> routing resolves flow_id and intake capability
  -> voice asks permission to text intake link
  -> SMS contains follow-along/intake link plus spoken verification code
  -> caller reads the code on the call; phone is marked verified
  -> voice collects L0 or confirms caller-ID-derived phone
  -> SMS link opens /intake/<token> when the intake page exists
  -> page loads schema + existing call/session values
  -> caller submits L0, then optionally fills modules
  -> intake events attach to the same call/session record
  -> voice flow can continue, summarize, schedule, message, or handoff

Privacy, Security, Points, and Credit

• Tokens are short-lived, signed, and scoped to one intake session.
• phone_verified verticals require passcode or verified channel before showing PII-rich answers.
• The browser never receives provider secrets.
• PageAgent/debug tools are disabled by default for production intake pages.
• Passwords are not intake fields.
• Raw card numbers, bank details, and CVV are not intake fields.
• Points/rewards are represented as opt-in and ledger/account references, not mutable client-side balances.
• Credit/payment setup uses hosted provider handoff; RIFF stores only safe references and display metadata.

PageAgent and Codex Debug

/space-agent.html?line=321-559-MARS
/intake.html?line=321-559-MARS&debug=1
/intake.html?flow=legal_intake&capability=start_intake&fixture=cooperative

Codex should verify routed-line mapping, required L0 fields, optional skips, optional resume, points enrollment, security handoff, credit handoff, PII gating, shared rendering, and replayable trace events.

Fable 5 Review Packet

RIFF wants progressive web intake generated from Business Packs.

The voice call collects L0: name, callback phone, consent to text, and intent.
The web page collects exact strings, optional detail, attachments, points/rewards
enrollment, security setup preference, and credit/billing handoff preference.
Space Channel, legal, plumber, and electrician intakes must share one contract.

Questions:
1. Is the split between business setup intake, caller problem intake, and caller
   profile intake correct?
2. Is the L0/L1/L2/L3 tier split the right product boundary?
3. What fields should be mandatory vs optional for Space Channel, legal,
   plumbing, and electrical?
4. Is "no raw password in intake; use auth handoff" the right security rule?
5. Is "no raw card fields in intake; use hosted credit/payment handoff" the
   right billing rule?
6. What should points/rewards mean without making the page feel like account
   setup before value?
7. What must the pack compiler validate before runtime?
8. What should PageAgent/Codex test for each new intake flow?
9. Which vertical-specific guardrails are missing?

Build Order

1. Add a static /intake.html prototype that loads a fixture schema.
2. Add Space Channel, legal, plumber, and electrician fixture schemas.
3. Add a schema validator for progressive tiers and required L0 fields.
4. Add draft save/submit endpoints with fake storage.
5. Connect routed-line selection through /api/page_agent/flow_targets.
6. Add PageAgent presets for L0-only, full intake, points, security handoff, and credit handoff.
7. Wire the Business Pack compiler to emit the web intake schema.
8. Add phone-verified passcode unlock for PII-rich verticals.
9. Add attachment handling.
10. Add hosted auth and credit/payment handoff stubs.
11. Promote to live SMS links once local and L1 evidence are clean.

Acceptance

• Space Channel profile intake can submit with phone-only context, optionally adding email, topic preferences, points, security setup, and credit handoff.
• Legal, plumber, and electrician intakes can submit L0 only and optionally add vertical detail.
• The same renderer handles all four examples.
• No password field and no raw card field exists in the intake schema.
• Replay evidence shows L0, optional section, points, security handoff, and credit handoff events.
• PII is not visible on bearer links for phone_verified flows.