Phase 220

Lead Triage Decision Policy

The policy layer that tells future reviewers when to reject, correct, hold, route, escalate, or mark a public lead packet review-ready.

Design decision

Policy before action

The queue can have clear decisions before FAEDA builds any live lead runtime. This prevents random sales follow-up, unsafe onboarding, and fake verification claims.

Phase boundary

Decision policy, no decision runtime

Phase 220 designs the public lead triage decision policy only. It does not update lead records, contact visitors, assign agents, create CRM tasks, create accounts, verify identity, approve onboarding, activate listings, create orders, create payments, create wallets, or sync data to partners.

Outcomes

6

Runtime

0

Auto ops

0

Decision outcomes

policy only

Decision outcome

Reject safely

Spam, fake, abusive, out of scope, or impossible to handle without unsafe data.

Mark future packet as rejected with a safe reason code and no public accusation.

No blacklist, no punitive scoring, no external reporting, no user contact.

Decision outcome

Request correction

The packet is useful but missing consent, role clarity, safe message, or area scope.

Prepare a future correction request packet with simple instructions.

No SMS, WhatsApp, email, push, or agent task in this phase.

Decision outcome

Hold for consent

Operational follow-up consent is missing, unclear, expired, or revoked.

Place the future packet in consent hold.

No follow-up, marketing, or sales activity.

Decision outcome

Route to role lane

The lead has clear intent for customer, shop, supplier, manufacturer, rider, partner, or unsure.

Tag the future packet for the correct role review lane.

No role account, no listing, no onboarding approval.

Decision outcome

Escalate to supervisor

High risk, legal concern, sensitive data, duplicate conflict, safety issue, or unclear role ownership.

Flag for supervisor review with risk reason and masked detail.

No direct founder alert, public claim, or emergency action.

Decision outcome

Mark review-ready

Clean packet, clear role, valid consent label, no sensitive data, no duplicate conflict.

Move the future packet to review-ready for a later approved workflow.

Still no contact, assignment, onboarding, account, or external sync.

Decision matrix

Condition to decision to lock

No operational consent

Decision: Hold for consent

Lock: No contact allowed

Sensitive data found

Decision: Reject safely or request correction

Lock: Raw sensitive content stays hidden

Duplicate high risk

Decision: Escalate to supervisor

Lock: No auto-merge

Role unclear

Decision: Request correction or route to unsure

Lock: No account creation

Business claim too strong

Decision: Request correction

Lock: No verification claim

Clean customer interest

Decision: Mark review-ready

Lock: No order or payment

Clean shop interest

Decision: Route to shop lane

Lock: No shop activation

Clean supplier interest

Decision: Route to supplier lane

Lock: No supplier approval

Clean manufacturer interest

Decision: Route to manufacturer lane

Lock: No Business Pro activation

Clean rider interest

Decision: Route to rider lane

Lock: No rider registration

Reason codes

Future backend-safe reason language

CONSENT_MISSING

Operational follow-up consent is not present.

SENSITIVE_DATA

Public packet contains blocked private or financial data.

ROLE_UNCLEAR

The requested FAEDA role is unclear or mixed.

DUPLICATE_RISK

Similar lead pattern needs human duplicate review.

OUT_OF_SCOPE

The request is outside public lead capture scope.

UNSAFE_MESSAGE

The message includes abuse, threat, or unsafe instruction.

NEEDS_SUPERVISOR

Reviewer cannot safely decide alone.

REVIEW_READY

Packet is clean enough for a later approved review workflow.

Priority policy

What gets blocked, escalated, triaged, or ready

P0 Block

CNIC, bank, password, OTP, medical, payroll, invoice, exact address, or file upload reference appears.

Block or correction gate

P1 Supervisor

Legal, safety, abuse, duplicate conflict, fraud risk, or public claim risk.

Escalate to supervisor

P2 Triage

Valid consent but role, area, or message needs interpretation.

Route, correct, or hold

P3 Ready

Clean, clear, consented, and role-scoped packet.

Mark review-ready

Audit fields

Future decision evidence shape

decisionIdrequestIdpreviousQueueStateproposedQueueStatedecisionOutcomereasonCodereviewerRoledecisionNoteMaskedconsentVersionsensitiveDataFlagduplicateRiskcreatedAt

Blocked automation

The decision policy must not automate these

1Auto reject public visitors without human reason
2Auto contact leads after review-ready status
3Auto route to freelancer, sales, rider, or city team
4Auto verify phone, CNIC, business, address, or bank
5Auto create customer, shop, supplier, manufacturer, rider, or partner account
6Auto generate commission, wallet, payment, order, RFQ, or ledger entry
7Auto expose raw sensitive content to founder or reviewer dashboards
8Auto export lead data to CSV, WhatsApp, SMS, CRM, partner, or government API

Reviewer duties

Who can decide what later

Intake reviewer

Can apply obvious hold, correction, route, or safe rejection draft.

Safety reviewer

Owns sensitive-data and unsafe-message decisions.

Duplicate checker

Owns duplicate risk and possible future merge review.

Role router

Maps lead to customer, shop, supplier, manufacturer, rider, partner, or unsure lane.

Supervisor

Approves high-risk decisions and review-ready policy exceptions.

Founder observer

Sees aggregate triage health, not raw private lead content.

Escalation rules

When a reviewer must not decide alone

1Escalate if a reviewer is unsure about privacy, legal, safety, or role impact.
2Escalate when a lead claims government, bank, medical, legal, or emergency status.
3Escalate when duplicate risk conflicts with a high-value supplier, manufacturer, or shop path.
4Escalate when the message asks for wallet, payment, loan, credit, payout, or account recovery.
5Escalate when reviewer notes may require redaction before future storage.

Acceptance checklist

Definition of lead triage decision policy

1Phase 219 links forward to Phase 220.
2Phase 220 defines triage decision policy without live lead mutation.
3Decision outcomes cover reject safely, request correction, hold for consent, route to role lane, escalate to supervisor, and mark review-ready.
4Decision matrix maps common conditions to allowed decisions and hard locks.
5Reason codes and audit fields are defined for future backend implementation.
6Blocked automation prevents auto-contact, auto-verification, auto-account creation, payment, wallet, CRM, export, and partner sync.
7OS launcher, founder navigation, public scope lock, route cleanup, and main chain control room include Phase 220.
8Mobile render has no horizontal overflow.
9No `/home` backlinks are introduced.

Next phase

Phase 221: Lead Assignment Approval Gate

Next we design the approval gate before any future lead can be assigned to a role lane, FAEDA Team owner, reviewer, or support path.

Open Phase 221
Phase 219 Phase 221