Role surface
Builder has a dedicated public route, navigation entry, and softened role copy.
A clear Builder guide for 21-level network structure, source-backed activity, compliant sharing, and Partner Kit handoff without income guarantees.
The public route explains the role, the tree vocabulary, and the proof labels users should expect before stronger claims appear.
Builder has a dedicated public route, navigation entry, and softened role copy.
Tree terms and income-event states are described as product boundaries, not live payout proof.
Partner Kit attribution is blocked/limited until KB#3446 repair proof closes.
The route may describe a 21-level tree because that is the accepted role architecture. It must not imply every branch is active, qualified, payable, or withdrawable.
A direct Builder relation can be explained only after attribution source and anti-abuse checks are accepted.
Branch depth shows structure. It does not prove activity, qualification, payable status, or earnings.
Deep levels stay educational until canonical referral, event, and ledger sources agree.
Level 21 is a product boundary, not a promise that the outer tree exists or pays.
If source, freshness, status, or digest is missing, stale, or blocked, the route keeps the explanation static instead of inventing numbers.
A Builder event needs source, qualification, ledger state, and separate finance proof before users can treat it as earned or withdrawable.
Clicks and codes remain a launch gate until matched clicks and referred-code users are proven.
Runtime activity can be described only through its own health, journal, and payout proof chain.
Partner Kit can educate and hand off, but it is not a proven acquisition or income engine yet.
Earned, pending, hold, and withdrawable states require separate ledger, reconciliation, and financial proof.
Future Builder incentives stay labeled as roadmap until release, runtime, and finance evidence exist.
KB#3446 found serious attribution proof gaps: clicks existed, but matched clicks and referred-code users were not proven. The public handoff can educate, but cannot look like a ready acquisition engine.
Builder messaging must help people understand PocketNode without pressure, spam, or invented outcomes.
Do not promise a fixed percent, passive income, forever income, or payout readiness without fresh proof.
Use approved education paths and avoid mass unsolicited outreach.
Every strong claim needs source, freshness, and a clear does-not-prove boundary.
Use Partner Kit, Academy, and prepared materials before custom claims or hand-written tracking links.
Bought traffic, bots, fake screenshots, or misleading referral posts should be reviewed before any growth credit.
Keep the source link, channel, timestamp, and screenshot so support can review evidence without exposing private data.
Users should move from role context to education and proof surfaces without confusing docs, runtime, release, or financial truth.