Settlement now acts as the Day 8 commercial source of truth: ledger stage, revenue-share split, payout policy, and hold profile all stay visible before live payout execution and callback proof are connected.
Module Entry Map
Day 9 keeps settlement ledger, revenue-share, release policy, and payout batch entry points explicit now, so real payout release work can attach to stable routes instead of late placeholder links.
把 settlement ledger、revenue share、release policy、payout batch 这些二级入口先做成独立占位面，避免后面接真实 payout 时再改信息架构。
为 usage-derived settlement ledger、stage progression 与 operator audit 预留独立台账入口。
为 share profile、gross/net split、launch partner exception 与后续 override 预留独立入口。
为 payout policy、threshold、hold profile、verification gate 与 operator hold 预留独立策略入口。
为未来 payout batch、callback proof、provider retry 与 release timeline 预留独立批次入口。
Settlement
Module 5 Day 8 now turns settlement into shared commercial truth instead of a placeholder shell. Usage receipt, hold window, revenue-share split, payout policy, and release posture all stay readable from one workbench before real payout execution exists.
Service boundary: foundation-control-plane-service
Eligible
1
Hold
1
Scheduled
1
Ledger rows
9
Day 8 fixes the settlement ledger stages as shared truth so payout readiness never hides inside finance-only notes.
Settlement starts from accepted usage, not from a later payout callback or spreadsheet export.
The first settlement row should be written when accepted usage becomes durable, so revenue-share math always points back to the same commercial receipt that already explains customer billing.
Upstream
Downstream
Revenue share waits in a hold window before it can become payout-eligible.
Hold state protects the platform against refunds, disputes, operator review, and supplier verification gaps without erasing the underlying commercial receipt.
Upstream
Downstream
Eligibility means the share is ledger-valid and can be considered for release, not that it already left the platform.
Thresholds, hold windows, account verification, and operator rules all need to pass before the payout policy can mark a settlement batch as release-ready.
Upstream
Downstream
Scheduled means the release path is chosen and visible before real payout execution exists.
Scheduling keeps the operator-visible release intent durable before live payout callbacks, provider receipts, and reconciliation jobs are built.
Upstream
Downstream
The split model, release policy, and hold contract are now explicit instead of being implied by payout account notes.
Revenue share
Keeps first-party or owner-operated services inside the same settlement ledger shape before third-party payout logic widens.
Internal reference share still writes gross, net, and stage posture so the settlement system can be validated without pretending every supplier is already an external marketplace partner.
Use when the service is official, owner-operated, or only needs settlement visibility rather than marketplace remittance.
The default commercial split for reviewed marketplace supply once accepted usage becomes durable.
Standard share makes the platform fee explicit in the ledger before any payout queue runs, so usage, marketplace policy, and supplier remittance stay reconcilable from one source of truth.
Use for normal third-party supply after the listing and payout route both satisfy the standard commercial contract.
A lower platform fee reserved for early or strategic suppliers where the partnership terms should remain explicit.
Launch partner pricing should never hide in notes alone. The ledger needs the exact split profile so later policy review and payout audits can explain why one supplier earns a different take rate.
Use for time-bounded or contract-backed partner exceptions that still need normal hold and payout controls.
Payout policy
Every release stays behind an operator review even after threshold and hold checks pass.
This is the safest starting point for first-party supply, internal finance review, or any supplier path that should not auto-release while payout execution is still a reserved future capability.
The system can schedule a payout batch automatically after threshold, hold, and verification checks clear.
This is the default policy for low-risk verified payout routes where the operator still needs a visible queue but does not want to approve each release by hand.
The settlement can become eligible, but scheduling stays blocked until the payout route satisfies verification requirements.
This profile is useful when the commercial contract allows automation, yet supplier identity, payout account posture, or risk review is still catching up.
Hold policy
The default hold window for normal marketplace or first-party commercial activity.
This profile keeps the revenue share visible while protecting the platform against chargebacks, refunds, and late operator review before payout becomes eligible.
Hold remains active until payout account or supplier verification catches up, even if the base time window already passed.
Verification watch prevents the system from auto-releasing to an untrusted payout destination while still keeping the supplier's earned balance visible and auditable.
Used when refunds, abuse review, or operator flags require the hold window to stay frozen until a human resolves it.
Dispute watch is intentionally stricter than the normal clock-based hold because commercial exceptions should remain obvious in the ledger instead of disappearing into support notes.
Each window now carries share profile, ledger stage, and next release action before live payout batches exist.