Portfolio Control and Creator Marketplace Awareness

One growth proposal, two independent decisions

Imagine a learning platform that already exports learner artifacts and manually features a small set of creators. A proposal arrives as a single feature request: build a Portfolio Control layer and turn it into an open Creator Marketplace. The wording hides two different problems.

Portfolio Control is an internal provenance, version, approval, and promotion-governance problem. A reviewer needs to know where an artifact came from, which revision is current, who approved it, and why a particular version is eligible for promotion. A Creator Marketplace adds a separate commercial and operational system: creator supply, buyer demand, transaction intent, payment and payout responsibilities, rights evidence, moderation, disputes, fraud and trust controls, and ongoing support ownership.

W3C PROV describes provenance in terms of entities, activities, agents, and derivation, making origin and production history explicit. [W3CPROV] That fact can support portfolio traceability; it does not define MAKNOW approval or promotion policy. Stripe Connect documents marketplace/platform payment flows involving connected accounts and platform responsibilities that depend on the integration model. [STRIPECONNECT] Payment capability does not prove demand, rights readiness, moderation capacity, or marketplace viability.

The working artifact is Portfolio/Creator Marketplace Control Decision Record v1. It contains two distinct decision axes: PORTFOLIO_CONTROL and CREATOR_MARKETPLACE. Allowed states are USE, PILOT, NOT_NOW, UNKNOWN, EVIDENCE_INCOMPLETE, OWNER_MISSING, REVIEW_REQUIRED, HOLD, PARTIAL, and DISPUTED. Incomplete decisive evidence never becomes a positive state by optimism.

Planned active time: 45 minutes.

This lesson is for learners who must justify portfolio governance and marketplace adoption with auditable evidence rather than with technology preference.

It is not authority to launch a live marketplace, move real money, create legal rights, alter production data, or absorb the outcomes of AWR-005 or AWR-007.

HARD prerequisite — AWR-005

Before continuing, state the relevant AWR-005 boundary in one sentence: which adjacent capability or architecture fact fails to create adoption authority without local problem evidence and an accountable owner? Then name one AWR-005 non-goal that must stay outside the Portfolio/Marketplace decision. If you cannot do both, do not use the fast path.

Bounded bridge: recover and record only this rule—capability or growth is not an adoption trigger by itself; the decision must bind problem, measured evidence, owner, cost/risk, and scope boundary. This bridge does not fabricate AWR-005 completion and does not replace its outcome.

Diagnose the missing evidence before designing the system

Answer four diagnostic questions:

1. Portfolio volume triples, but revisions remain well identified, provenance is traceable, and promotion volume is low. Does volume alone justify a new Portfolio Control system?
2. One thousand creators have profiles, but buyers make only a few requests each month. Does creator supply alone justify a transactional marketplace?
3. A provider offers payment APIs and connected accounts. Does that also prove rights, moderation, dispute ownership, and fraud control?
4. Buyer demand becomes strong, but rights evidence is missing for a material share of works. Can the marketplace move directly to USE?

4/4 correct: fast path. 2–3/4: repair path. 0–1/4: foundation path. The fast path compresses definitions; it never lowers the evidence bar, negative-case coverage, or transfer requirement.

Route self-check: do not merge portfolio governance with marketplace economics; do not substitute creator count for buyer demand; do not treat payment capability as operational readiness; and do not treat NOT_NOW as failure.

Mental model: two axes, two evidence chains

Portfolio chain:

PORTFOLIO_CONTROL → provenance/version gap → approval/promotion need → owner + operating cost → simpler control → bounded state

Marketplace chain:

CREATOR_MARKETPLACE → creator supply + buyer demand + transaction need → payment/payout → rights → moderation/disputes → trust/fraud → owner + cost → simpler alternative → bounded state

The crucial implication is that a marketplace is not the natural next state of a portfolio. A platform can need rigorous portfolio control because it manages thousands of revisions and promotion requests while a marketplace remains NOT_NOW because buyer demand is thin.

Keep three authority layers separate:

If the diagram cannot render, this ordered text is the complete fallback for asset://AWR-006/AWR-006-ASSET-FLOW.

Foundations: evidence required on each axis

PORTFOLIO_CONTROL

Record at least:

• problem: the control problem being evaluated on this axis;
• portfolio_object: the artifact or collection being governed;
• revision_id: the revision under review;
• provenance_ref: the traceable origin/derivation reference;
• approval_state: the visible review or approval state;
• promotion_need: the measured reason controlled promotion is needed;
• operational_owner: the role accountable for governance;
• operational_ownership_cost: the review, metadata, escalation, or operating burden—never invented real pricing;
• simpler_alternative: existing metadata/version discipline, manual curation, or a narrow approval queue;
• decision_state, rationale, review_due, and evidence_ref.

W3C PROV gives useful provenance concepts. [W3CPROV] It does not decide which artifact MAKNOW should promote; promotion and approval rules remain DESIGN authority.

CREATOR_MARKETPLACE

Record at least:

• problem: the two-sided or transactional problem being evaluated on this axis;
• creator_count and the quality of usable creator supply;
• buyer_demand with a measurable evidence source;
• transaction_frequency, distinguishing repeated demand from isolated requests;
• marketplace_role: directory, referral, broker, or payment facilitator;
• payment_flow and payout_owner;
• platform_fee_model, if applicable, without inventing accounting or legal advice;
• creator_onboarding evidence;
• rights_evidence for offering, selling, or displaying the work;
• moderation_owner and dispute_owner;
• fraud_risk and observable trust_signal;
• simpler_alternative: directory, referral workflow, or invite-only pilot;
• operational_owner and operational_ownership_cost;
• decision_state, rationale, review_due, and evidence_ref.

Stripe Connect shows that marketplace payment flows are technically available. [STRIPECONNECT] That fact cannot substitute for demand, rights, or ownership evidence.

Build Portfolio/Creator Marketplace Control Decision Record v1

Step 1 — Create two independent decision rows

Keep PORTFOLIO_CONTROL and CREATOR_MARKETPLACE separate. A single maturity score hides the case in which one axis is justified and the other is not.

Step 2 — Bind the portfolio problem to provenance and version evidence

A real portfolio-control gap exists when origin, revision, approval, or promotion history cannot be reconstructed reliably enough for the operating need. If the existing system already provides those controls at low burden with a clear owner, a new control layer may remain NOT_NOW. Artifact volume alone is not the trigger.

Step 3 — Measure a two-sided marketplace trigger

Creator supply is only one side. Buyer demand and transaction intent must be observed independently. A large creator catalog does not become a market merely because supply exists.

Step 4 — Separate provider capability from platform responsibility

Payment is one gate, not the whole system. A positive marketplace state also needs rights, payout ownership, moderation, dispute handling, fraud/trust controls, and operational support. If the owner is absent, OWNER_MISSING is more honest than a success state.

Step 5 — Compare a simpler alternative

Portfolio governance may be solved with disciplined metadata and an approval queue. Marketplace demand may be tested with a directory, referral workflow, or invite-only pilot before a full transaction layer. This simpler-alternative rule is a MAKNOW DESIGN choice used to resist premature complexity; it is not an external FACT.

Step 6 — Never make the state stronger than the evidence

NOT_NOW is legitimate when the measured trigger is absent. If the trigger may exist but decisive evidence is missing, preserve UNKNOWN, EVIDENCE_INCOMPLETE, OWNER_MISSING, REVIEW_REQUIRED, HOLD, PARTIAL, or DISPUTED. Missing evidence is not the same as evidence that the trigger is absent.

Step 7 — Name review, stop, or pivot triggers

Reopen the decision when measurable buyer requests change, transaction frequency changes, rights evidence closes, payout ownership changes, dispute load increases, provenance fails, or the simpler alternative stops serving the core demand.

Worked example: portfolio control may advance while marketplace stays bounded

This example is separate from the executable lab and does not pre-solve its fixtures.

Synthetic platform SYNTH-CREATOR-B holds about 2,400 artifacts with multiple revisions. Editorial teams receive repeated requests to feature selected work, but they cannot reliably reconstruct which revision was approved or why it was promoted. Provenance references and approval state are inconsistent, and review ownership is fragmented. A bounded metadata and approval workflow addresses a real governance gap. With visible ownership and operating cost, Portfolio Control could reasonably move to PILOT and, with sufficient evidence, eventually USE.

The same platform has 320 active creators but only nine buyer requests over the last ninety days. Transaction frequency is not established. A payment integration is technically possible, yet rights evidence is incomplete for a material set of works and no dedicated marketplace moderator exists. Those facts do not support a full transactional launch. A directory or invite-only referral path can test demand at lower operational burden, so NOT_NOW or an explicitly non-transactional PILOT can be the bounded result.

This table preserves the source specification for asset://AWR-006/AWR-006-ASSET-TABLE even when a visual table is unavailable.

Shortcuts that create false confidence

1. portfolio volume → marketplace: more artifacts or creators does not prove buyer demand.
2. payment capability → launch: payment without rights, moderation, disputes, and ownership is only a capability.
3. strong demand → ignore rights: buyer demand cannot erase missing rights evidence; keep a non-success state until the decisive evidence exists.
4. payment + no operations owner: payout, moderation, and dispute ownership remain blocking evidence dimensions.
5. one combined verdict: Portfolio Control can be USE while Marketplace is NOT_NOW; a combined label hides the difference.
6. NOT_NOW = failure: when the measured trigger is absent, NOT_NOW is a valid anti-complexity decision.
7. missing evidence = NOT_NOW: uncertainty is not a negative measurement. Use UNKNOWN, EVIDENCE_INCOMPLETE, or HOLD when the issue is missing evidence.
8. vendor docs = MAKNOW policy: external sources describe mechanisms and capabilities; MAKNOW decides adoption thresholds and states.

Required counterexample: increase buyer demand but remove rights_evidence. If the marketplace remains USE or PILOT, the decision violates the evidence contract.

Experienced bridge: do not couple the state machines

Experienced learners can compress definitions and defend transitions instead. The Portfolio state machine advances only when the provenance/version/promotion problem, owner, and operating burden are visible. The Marketplace state machine separately evaluates two-sided demand, transaction intent, payment/payout, rights, moderation/disputes, trust/fraud, and ownership.

Defense exercise: assume Portfolio Control has reached USE. Without using that status as evidence for the marketplace, identify what would have to change for Marketplace to move from NOT_NOW to PILOT. Then name one stop condition that would return the pilot to HOLD. If your justification is merely “the portfolio is ready,” the two state machines have been coupled incorrectly.

Trade-offs without a permanent winner

For Portfolio Control, compare three levels: disciplined metadata/versioning in the current tool, a bounded approval queue, and a richer control layer. The simpler option has lower integration and governance burden but may eventually fail to provide the searchability, audit trail, or promotion throughput required at larger scale.

For Creator Marketplace, compare a directory/referral path, an invite-only pilot, and a full transactional marketplace. The full marketplace can capture transactions and create richer matching, but it also introduces payout/reconciliation, rights, moderation, disputes, fraud/trust, support, and operating ownership. When demand is thin, those obligations can be ahead of the problem.

There is no permanent winner. The record must state which alternative fits the current constraint and what future trigger would change that choice.

Guided and independent practice

lab://AWR-006/AWR-006-LAB1 is a fully synthetic offline decision fixture. The starter contains no prefilled verdict. You construct two evidence records; the checker validates exact fixture binding and visible consistency rules only. There is no hidden answer-key artifact.

Run the sequence:

1. Build both axes from the baseline fixture.
2. Apply the mutation “increase portfolio volume without increasing buyer demand” and recompute only the affected reasoning.
3. Apply “add strong buyer demand but remove rights evidence”; a marketplace success state is not allowed.
4. Apply “add payment capability but no moderation or dispute owner.”
5. Replace the full marketplace with an invite-only referral workflow and evaluate whether the core demand is still served.
6. Run the missing-decisive-evidence fixture; HOLD, UNKNOWN, EVIDENCE_INCOMPLETE, PARTIAL, or another appropriate non-success state must remain possible while success is rejected.
7. Rebuild the transfer fixture independently. The baseline verdict is never an oracle.

AI may organize supplied synthetic evidence or run deterministic checks. It may not invent an owner, demand, rights evidence, fee model, trust signal, or approval.

Verification: the reviewer must reconstruct the decision from evidence

For each row, confirm that:

• the axis is explicit and independent;
• evidence references resolve to visible fixture or source records;
• the Portfolio row exposes revision/provenance/approval/promotion need when relevant;
• the Marketplace row keeps creator supply distinct from buyer demand;
• transaction need, payment/payout, rights, moderation/disputes, and trust/fraud are not silently skipped;
• an accountable owner and operating/ownership cost class are visible;
• a simpler alternative was actually compared;
• the state is no stronger than the evidence;
• missing decisive evidence did not become a positive state;
• review due and stop/pivot conditions are stated;
• external FACT claims remain bounded to [W3CPROV] and [STRIPECONNECT], while MAKNOW DESIGN is not presented as vendor fact.

If a reviewer must guess a decisive field, the evidence package is incomplete.

Assessment and transfer

Formative checkpoints:

• AWR-006-F1: explain the owned boundary and one adjacent non-goal.
• AWR-006-F2: diagnose increased portfolio volume without increased buyer demand; name the invalidated field/state and repair path.
• AWR-006-F3: recompute the changed-context transfer rather than copying the baseline.

Summative tasks:

• AWR-006-S1 tests boundary retrieval.
• AWR-006-S2 tests construction of the full Decision Record from the baseline synthetic fixture.
• AWR-006-S3 tests negative-case diagnosis.
• AWR-006-S4 tests transfer.

Required transfer: a second platform has thousands of versioned portfolio artifacts and strong demand for controlled promotion, but only a handful of buyer requests. Recompute both decisions. Portfolio Control can be USE while Marketplace remains NOT_NOW or PILOT, but the justification must come from the changed evidence rather than from the baseline result.

References, freshness, and claim boundaries

[W3CPROV] — W3C PROV Overview. Used for provenance, entity, activity, agent, and derivation concepts. It does not define MAKNOW portfolio approval, promotion policy, or marketplace triggers.

[STRIPECONNECT] — Stripe Connect marketplace documentation. Used for platform/connected-account payment-flow capability and responsibility framing. It does not establish creator demand, rights readiness, moderation capacity, or viability.

The sources [W3CPROV] and [STRIPECONNECT] were retrieved on 2026-09-03 and are due for review on 2026-12-02. Keep external FACT and MAKNOW DESIGN separate. If relevant source semantics materially change before that review date, recheck the affected claims; this lesson relies only on the claim limits stated in this references section.

Keep uncertainty visible: synthetic fixtures do not prove production payment or payout behavior, live marketplace operations, customer-data handling, or legal rights. Business constraints and owner policy can also change without any change in the external technical facts.