AHD - Embraced AI seal

AHD - Embraced AI

Sales Rep Referrals

First-Party Attribution

Rep links should identify the source of an inquiry without becoming surveillance.

Sales rep attribution will use simple first-party rep codes and deterministic request binding. No cookies, no external trackers, no fingerprinting, and no backend logic in this first phase.

Ask questions Use intake when ready

The Architecture Phases

Phase 1 - Link structure only.

The first phase defines URL conventions and rep codes only. It does not store events, create records, bind submissions, or process attribution in the backend.

Homepage linkhttps://embraced-ai.com/?rep=rep-code
Intake linkhttps://embraced-ai.com/intake/?rep=rep-code
Contact linkhttps://embraced-ai.com/contact/?rep=rep-code
VIP linkhttps://embraced-ai.com/vip/?rep=rep-code

URL Convention

Use ?rep= for the initial public convention.

Rep codes should be short, stable, lowercase, and readable. They should identify the assigned rep without exposing private information.

Format?rep=rep-code
Example?rep=rep-michael
Allowed stylelowercase letters, numbers, and hyphens
Do not includeprivate customer data, phone numbers, private email addresses, or sensitive identifiers

Rep Codes

Rep codes identify the referral path.

Rep codes are not user accounts, passwords, payment records, or customer profiles. They are attribution labels that can later be bound to deterministic intake or contact receipts.

Stable

A rep code should not change casually once shared.

Readable

A rep code should be easy to identify in admin summaries later.

Non-sensitive

A rep code should not contain private customer or personal data.

Phase 2 - Backend Capture Soon

Worker reads ?rep=.

In the next backend phase, the Worker can read the rep code and create a first-party attribution receipt. This should be a minimal event, not a tracking system.

Storesrep code, landing path, timestamp, and request reference
No PIINo submitted personal data is captured at this phase.
No cookiesNo persistent browser tracking is required.
No trackingNo external analytics, pixels, fingerprinting, or customer-side telemetry.
First-party event onlyA bounded attribution event owned by AHD - Embraced AI.

Phase 3 - Intake / Contact Binding

Attribution becomes real at submission.

When a user submits intake or contact, the rep code can be attached to the request receipt. This is the point where attribution becomes a governed record.

Inputsubmitted intake or contact request
Bindingrep code attaches to the request receipt
Boundaryno authority, no payment action, no workspace creation

Phase 4 - Admin Visibility

Admin backend shows attribution summaries.

Admin visibility belongs only in the protected sovereign backend. Rep summaries should be shown as first-party business records, not surveillance data.

rep -> inquiriesWhich inquiries were attributed to the rep.
rep -> conversionsWhich attributed inquiries became approved commercial paths.
rep -> package interestEGAE, Security Suite, Verity, Steward HUD, VIP, or workspace interest.
rep -> timestampsDeterministic timing for inquiry and conversion records.

Phase 5 - VIP / Customer Flow

VIP records can show assigned rep context.

Later VIP records may show rep attribution where appropriate, but VIP remains separate from sovereign admin.

Assigned repThe rep associated with the licensed path.
Rep attribution historyBounded attribution history tied to request receipts.
Rep performance summariesApproved summaries visible only through appropriate protected surfaces.

Final Rule

Referral attribution is first-party, bounded, and receipt-based.

The current phase defines the link structure only. Backend capture, intake binding, admin summaries, and VIP record visibility come later.