OFM creator lifecycle domain

Owner: OFM-CREATOR-DEEP Date: 2026-08-29 Status: URGENT MILESTONE COMPLETE; deep sourcing, ranking and proof plan complete Write boundary: this file only. repo/ and Oracle Streaming were inspected read-only.

Evidence key and boundary

• [F] Fact: directly observed in a cited local file, campaign brief, or protected

prior-art document.

• [VC] Vendor claim: a product/company's own description; useful for capability

discovery, not proof of fit, quality, safety, or actual customer outcomes.

• [I] Inference: reasoned from facts or multiple sources.
• [P] Product proposal: original recommendation for the future HALO composition.
• [U] Unverified: a claim that needs a direct probe, interview, trial, or source check.

This is an operating-system map, not implementation authorization. Adult creator work must remain lawful and consent-led: verify adulthood and identity through an appropriate specialist process, minimize sensitive data, respect platform terms, require human review for consequential decisions, and never recommend credential theft, impersonation without authorization, or unreviewed automation.

Executive decision

[P] HALO should own the creator relationship and lifecycle control plane: one canonical creator ID; acquisition provenance; qualification and boundary records; consent/age/identity evidence status; contract and rights versions; creator-visible progress; access grants and revocation; renewal/hold/offboarding; referral attribution; and an exportable audit trail. The portal is a role-limited read model over those authorities, not a second creator database.

[P] Buy or integrate specialist boundaries: KYC/age/identity verification, e-sign and tamper-evident signature evidence, secrets/credential vaulting, payment rails, and possibly document retention. A vendor can verify or transport evidence; HALO must retain the status, purpose, source, version, expiry, consent scope, and revocation link needed to operate safely.

[P] Buzz is the collaboration/event plane, not lifecycle truth. The server-side adapter may post scoped tasks, reminders, approvals, and handoff links keyed by stable creator IDs. Contracts, identity evidence, credentials, rights, referrals, money, and lifecycle state remain in HALO/domain services. This follows the fixed product context and the prior-art authority split in research/ofm-domain-campaign/BRIEF.md and research/sourcing-campaign/buzz-integration.md.

[I] The highest-value missingness is not another profile form. It is a durable, creator-safe state machine that makes every handoff answer: what was promised, what the creator consented to, what is verified, who may act, what expires, and how to revoke/export it. The current app stores useful fragments but does not yet make that chain authoritative.

Persona and authority matrix

The “may see” column is the proposed minimum; it is stricter than the current browser role checks. A client-side role flag is not sufficient authorization for any sensitive action.

End-to-end operating journey

The authoritative record named in each step is the durable answer to “what happened?” Screens, chat messages, vendor dashboards and email are projections or evidence links.

0. Source, referral and consent to contact

Entry: a creator is found through outreach, inbound interest, an existing creator, or a referral partner. Capture source, referrer, timestamp, jurisdiction, contact channel, and the creator's consent to be contacted for this purpose. Dedupe on stable contact identity and a human-reviewed match, not display name alone.

Handoff: recruiting → lifecycle manager. Authoritative record: candidate plus append-only acquisition/referral provenance. Failure states: duplicate, no contact consent, underage/age unclear, prohibited jurisdiction or request, source dispute, bounced contact, or candidate withdrawal. Keep a minimal suppression/dispute record; do not retain unnecessary intimate details.

1. Qualification and mutual-fit decision

Use an adult-safe, non-coercive checklist: service fit, availability, location/jurisdiction, platform/account readiness, boundaries, desired representation, communication preferences, and commercial expectations. Record what was offered and what remains unknown. Do not turn intimate disclosures into a generic score.

States: new → contacted → responding → qualified → hold → declined → withdrawn. Handoff: recruiting → manager/compliance only with a structured, purpose-limited packet. Authoritative record: versioned qualification decision and reason code, with actor/time. Failure: candidate asks to pause, declines terms, fails safe eligibility, or cannot provide required evidence; route to a humane close/hold, not silent disappearance.

2. Offer, economics, rights and boundary negotiation

Create a versioned term sheet: agency split/commission, payout cadence/currency, services, platforms, content categories, likeness/voice usage, territory, exclusivity if lawful and freely agreed, availability, approval rights, takedown/expiry terms, support expectations, and exit terms. Every material change produces a new version and a creator-visible diff.

Authoritative record: agreement_draft / rights-and-boundaries version, linked to the candidate and eventual creator ID. Handoff: manager → admin/compliance → creator. Failure: disagreement, missing scope, ambiguous rate, or changed mind; keep prior draft, mark the negotiation unresolved, and do not activate from a chat promise.

3. Invitation and secure onboarding

Send a single-use, expiring invite to a minimal creator portal. Let the creator save/resume, see why each field is requested, distinguish public-safe profile data from restricted data, and submit only the evidence needed for the next gate. Record invite delivery and consent to the specific collection purposes.

Current HALO fact: the clone exposes /onboarding-form/:token and an admin-protected /onboard-queue; the multi-step form has personal info, physical attributes, preferences, and content/services steps and submits by token (repo/src/App.tsx:186-191, repo/src/components/onboarding/multi-step/MultiStepForm.tsx:26-75,268-390). The schema contains email, date-of-birth/age fields, social handles, preferences and pricing fields (repo/src/schemas/creatorOnboardingSchema.ts:5-118).

Current HALO fact: creatorInvitations.create creates a token and validateToken checks pending status plus absence of a submission, while expiresAt is currently undefined; submission stores free-form data and flips the invitation to completed (repo/convex/creatorInvitations.ts:38-56,75-92,107-143).

Authoritative record: onboarding case + immutable submission versions + invite/audit events. Failure: expired/revoked/used invite, partial save, duplicate submission, upload failure, or creator withdrawal. Preserve a resumable draft or explicit withdrawal; never treat a client-side “success” screen as acceptance.

4. Adult identity, age, consent and rights evidence

Run the minimum lawful adult/identity process for the operating jurisdiction through a specialist or controlled evidence workflow. Separate: (a) identity/age verification, (b) consent/release evidence for each person and use, (c) likeness/voice permissions, (d) platform/account ownership or authorization, and (e) expiry/revocation. A pass/fail boolean is insufficient: preserve provider, evidence type, subject, purpose, consent scope, version, performed-at, expiry, reviewer, and evidence location with strict access controls.

Gate: no contract activation, credential handoff, publishing, voice/likeness use, or paid work until required evidence is verified and not expired. Authoritative record: evidence ledger with status transitions and revocation links; vendor raw documents remain in the specialist vault when possible. Failure: mismatch, age unclear, consent missing/withdrawn, vendor outage, expired document, or jurisdiction conflict → quarantine, human review, notify creator, and block downstream actions. Never ask an agent or chatter to adjudicate identity.

5. Contract, signature and effective-date activation

Render the exact term version, let the admin sign first if required, show the creator a human-readable agreement/diff, obtain affirmative signature/confirmation, and issue a tamper-evident receipt. Effective date, rights scope, commission and termination terms must be linked to the signed version, not copied into mutable profile fields.

Current HALO fact: contracts.create creates a pending creator signature contract with admin signer data and a template version; signCreator moves it to completed after name, date and signature fields; cancel is available (repo/convex/contracts.ts:89-190). A creator profile renders a contracts card (repo/src/pages/CreatorProfile.tsx:61-77).

Current HALO fact: the public route is /contracts/sign/:token; the token generator uses random bytes encoded by per-byte base-36 strings, and the visible backend flow has no expiry field/check (repo/src/App.tsx:178-180, repo/convex/contracts.ts:6-10,76-85).

Authoritative record: signed contract package, template hash/version, signer identity, consent/receipt and state history. Failure: wrong version, signature dispute, link leak, duplicate sign, cancellation, or signer withdrawal → freeze activation and route to compliance/admin; never overwrite a signed version.

6. Accept, provision and hand off access

Once required evidence and contract gates pass, create or link one canonical creator record, creator-facing identity, portal entitlements, team assignment, Drive/content workspace, approved account-access references, and referral attribution. Provisioning is a saga with independent, retryable steps; the creator must see which step is ready or blocked.

Current HALO fact: accepting a submission creates profiles, authUsers, creators, social-link rows, starter invoicing, social-login rows, and schedules Drive provisioning (repo/convex/onboardingSubmissions.ts:106-229). Creator creation likewise schedules Drive provisioning (repo/convex/creators.ts:77-119).

Authoritative record: creator ID plus provisioning ledger and access-grant records. Failure: duplicate email, partial profile creation, Drive outage, missing team, failed credential handoff, or referral conflict. Idempotently retry or compensate; do not mark “active” while a required access/revocation step is unknown.

7. Creator portal readiness and first-work activation

Give the creator one transparent “ready for work” view: profile facts to confirm, approved voice/boundaries, content/request rules, schedule/availability, contracts, support, upload/ briefs, statements, and outstanding actions. The portal should reveal internal-safe status without exposing chatter deliberations or secrets.

Claimed model app check: the current clone has public/tokenized onboarding, public contract signing, an unprotected /upload/:id upload page, creator profile self-scoping, and creator-facing “My Social Media Accounts” copy inside the secure-logins page. These are real surfaces, but no separate complete model app/repository/deployment was located in the inspected clone and route map. [U] The client's claimed dedicated app remains open until the lead locates direct product/repository/deployment evidence.

Authoritative record: readiness checklist with evidence-backed gates and creator acknowledgement. Failure: creator cannot access portal, content guide is wrong, policy conflict, missing approval, or platform account unavailable → support queue and hold, not silent activation.

8. Operate, maintain relationship and renew

Maintain a relationship timeline of promises, approved changes, support issues, availability, rights/consent revisions, content/brief outcomes and statements. Renewal is a first-class workflow: forecast expiry, present the exact changed terms, re-confirm consent/rights, re-verify evidence where required, and create a new agreement version. No silent auto-renew.

Current HALO fact: creator records include profile/contact/social links, notes, team, marketing strategy, active state, and a terminatedAt field; model announcements and schedules are separate per-creator tables (repo/convex/schema.ts:41-99,472-495). Referrals preserve dated links and monthly history (repo/convex/schema.ts:147-212; see also repo/convex/referrals.ts:108-445).

Gap: no inspected first-class relationship timeline, renewal/term-version state machine, rights/consent revision history, creator support case, or creator-controlled export view.

9. Hold, suspend, incident and consent revocation

Any platform suspension, safety concern, evidence expiry, creator request, staff departure, dispute, or account compromise can place a creator or capability on hold. Use scoped holds (publishing, credentials, payouts, all operations) with reason, actor, expiry/review date, notifications, and reversible remediation. Consent revocation must propagate to affected assets, voice/likeness uses, access, and future automation.

Authoritative record: incident/hold and revocation event linked to affected grants, rights, content and platform accounts. Buzz may coordinate the response; HALO decides the hold and records the audit. Failure: missing acknowledgment, failed revoke, vendor outage, or competing instructions → fail closed and surface an exception to the owner.

10. Offboarding, final accounting and export

Agree the exit effective date and scope; notify the creator; stop new work; settle approved money; preserve referral history and contract evidence; revoke portal/team/Buzz membership, Drive shares, platform sessions and credentials; process takedown/expiry requests; produce a machine-readable export plus human-readable receipt; apply retention/deletion policy with legal holds where necessary.

Current HALO fact: creators.remove only patches active: false, while invoicing has a termination date and 14-day notice-window concept; referral code keeps departed creators and past links visible for history (repo/convex/creators.ts:210-216, repo/convex/schema.ts:46-53, repo/convex/invoicing.ts:100-140, repo/convex/referrals.ts:366-413).

Gap: no inspected lifecycle-wide offboarding saga, revocation receipt, export manifest, retention/deletion decision log, or guarantee that every vendor/Buzz/Drive permission is revoked. “Inactive” is not proof of exit completion.

Feature / sub-app tree

Creator Lifecycle OS
├── Acquisition & referrals
│   ├── lead/candidate intake and dedupe
│   ├── source / referral attribution with dispute history
│   ├── consent-to-contact and suppression list
│   └── outreach, follow-up, qualification and hold queues
├── Qualification & mutual-fit
│   ├── adult-safe eligibility checklist
│   ├── boundary / availability / jurisdiction capture
│   ├── structured decision reasons and reviewer handoff
│   └── candidate-to-creator conversion without duplicate records
├── Offer, economics & rights
│   ├── versioned term sheet and creator-visible diffs
│   ├── split/rate/currency/effective-date model
│   ├── content, platform, territory, likeness and voice scopes
│   ├── expiry, withdrawal, takedown and termination rules
│   └── negotiation/proposal audit trail
├── Creator onboarding portal
│   ├── expiring single-use invite and secure resume
│   ├── purpose-labelled, minimal fields
│   ├── public-safe profile vs restricted evidence separation
│   ├── uploads to specialist evidence/document storage
│   ├── progress, blockers, support and submission receipt
│   └── accessibility, localization and consent history
├── Identity, age & consent evidence
│   ├── KYC/age/identity vendor adapter
│   ├── evidence ledger and reviewer queue
│   ├── person/asset/use consent and rights matrix
│   ├── expiry/reverification/revocation
│   ├── retention/legal-hold policy
│   └── immutable audit and human escalation
├── Contracts & e-sign
│   ├── template/version registry
│   ├── draft → admin review → creator sign → effective → superseded/cancelled
│   ├── tamper-evident receipt and signer identity
│   ├── creator-visible history and export
│   └── specialist e-sign adapter
├── Creator record & relationship memory
│   ├── canonical profile and aliases
│   ├── approved voice/boundaries/rates/availability
│   ├── timeline of promises, changes, support and decisions
│   ├── notes with field-level visibility
│   ├── announcements/calendar/brief links
│   └── renewal and re-verification queue
├── Access & provisioning
│   ├── server-side RBAC/ABAC and creator/tenant scope
│   ├── portal entitlements and team assignments
│   ├── credential-vault reference, never plaintext password authority
│   ├── Drive/content workspace provisioning saga
│   ├── Buzz membership/resource-link adapter
│   ├── review, expiration and break-glass access
│   └── revoke/rotate/reconcile receipts
├── Read-only creator portal surfaces
│   ├── onboarding/readiness checklist
│   ├── contracts, rights, boundaries and approvals
│   ├── briefs, uploads, content status and support
│   ├── availability/schedule and announcements
│   ├── earnings/statements/referral status
│   ├── access status (no secret display by default)
│   └── export, revoke and leave requests
├── Holds, incidents & exits
│   ├── scoped hold/suspend/restore state machine
│   ├── consent revocation propagation
│   ├── account/platform suspension handling
│   ├── offboarding checklist and vendor revoke fan-out
│   ├── final statement/referral preservation
│   ├── machine-readable export manifest
│   └── retention/deletion/legal-hold receipt
└── Shared primitives / integrations
    ├── stable IDs, typed links, idempotency and event provenance
    ├── state transitions with actor/time/reason/version
    ├── evidence references and audit log
    ├── field-level visibility and redaction
    ├── notifications and human approval gates
    ├── HALO ↔ Buzz server-side adapter
    ├── KYC/age/identity and e-sign sidecars
    ├── secrets vault and payment rails
    └── export/restore and synthetic-data test harness

Optional later surfaces: creator mobile/PWA shell, self-serve referral portal, predictive renewal risk, AI-assisted profile normalization, and cross-platform account health. None is needed before authority, evidence, revocation and export are trustworthy.

Current HALO read-only coverage and gaps

Current HALO claimed model-app determination

Finding: [F] The clone's route map contains onboarding, signing, upload, roster/profile, secure login, Drive, announcements/schedules, invoicing and analytics surfaces. [F] The visible CreatorInviteOnboarding route has placeholder text for three tabs, while the MultiStepForm route is the substantive four-step form. [U] No independently located dedicated model-facing app/repository/deployment was established in this read-only pass.

Therefore, do not call a complete model app missing as a definitive claim yet; call it unverified. The next proof is a direct route/repository/deployment inventory supplied by the client or lead, followed by a creator-role smoke using synthetic data only. If it exists, map its authoritative IDs and boundaries rather than recreating its profile fields.

Search vocabulary (intent-first, not page-name-first)

The last row is operator vocabulary supplied by the campaign's follow-up evidence. The general diagnose → practice → observe → audit → coach → refresh loop is a useful adjacent control-loop hypothesis, not OFM-specific proof; vendor metrics and anecdotal operator claims remain untrusted until directly corroborated.

Internal prior art and crossover

Oracle Streaming [F]: the protected on-ramp defines one model-facing action that starts a multi-platform live workflow; viewer chat and tips enter one cockpit; real events drive goals and overlays; state persists to Convex. Its proof ledger records one-press go-live, real event ingestion, deduplication, goal advancement from approved event truth, media setup, and human-present/account-safety gates (research/ofm-domain-campaign/INTERNAL-PRIOR-ART.md; the current source checked was apps/oracle-streaming/docs/PROVEN-LEDGER.html).

Reusable patterns [I/P]:

• One low-cognitive-load action can start a bounded creator operation: resume onboarding,

submit a content approval, confirm availability, acknowledge a contract change, or request exit. The action should expose gates and evidence, not hide them.

• Typed IDs, event provenance, deduplication and timestamps can link Oracle, HALO and Buzz

without merging deployments or duplicating creator authority.

• Goals/rewards/readiness badges must derive from server-authoritative events, never a

client-supplied counter or decorative “completed” state.

• A creator-visible progress/readiness surface can share the transparency philosophy while

protecting staff notes, credentials, identity evidence and internal decisions.

• Oracle's explicit proof receipts suggest a HALO lifecycle receipt for contract, access,

consent, revocation and export transitions: status + actor + time + source evidence.

Non-transferable [F]: streaming transport, OBS/OME, platform connector/readback details, live chat/tip capture and webcam account-safety gates are specific to Oracle. They do not prove OnlyFans messaging, creator onboarding, consent, e-sign, or account-access authority. Shared Convex usage does not imply shared auth, tenancy, schema or deployment.

Claimed model app [U]: no additional model app was proven in the local pass. If the lead locates it, the crossover test is: does it own creator identity/consent/contracts or merely render a view? Reuse its creator-facing interaction patterns only after stable ID, permission, export, revocation and audit contracts are identified.

What are we still missing? — first-principles missingness map

The department exists to produce a creator relationship that is safe to activate, clear to operate, reversible when consent or risk changes, and portable when the relationship ends. Current screens mostly capture fields; the missing system is the continuity of obligations.

10× opportunity [P]: a creator “trust passport” is not a new marketing profile. It is a creator-controlled, purpose-limited readiness ledger: each capability (publish, chat, voice, custom request, payout, account access) shows the exact contract/consent/evidence/access prerequisites, expiry, responsible human, and revoke path. Managers get exception queues; creators get understandable progress and control; owners get proof that the agency can survive turnover, suspension and exit. This can be innovative while remaining conservative about data and automation.

Never build in HALO [P]: raw identity-document storage if a vetted specialist can retain it; a general-purpose e-sign cryptography stack; a password vault; money-movement rails; or a second chat/knowledge product. Integrate these behind explicit, testable authority contracts.

Urgent milestone receipt

Completed in this file before the sourcing campaign: persona/authority map, end-to-end journey, feature/sub-app tree, current HALO coverage/gaps, claimed-model-app determination, search vocabulary, Oracle crossover, and first-principles missingness map. The remaining sections below record the fresh corpus, GitHub, product and operator evidence, the resulting rejects, and a synthetic proof plan. They do not authorize a build, deployment, credential use, Convex mutation or change to the read-only clone.

Serena receipt: native Serena was not exposed in this runtime; the prescribed /Users/shaansisodia/bin/serena-fast fallback returned ECONNREFUSED 127.0.0.1:24225. The HALO code claims above therefore use narrow read-only rg/line reads after semantic transport failure, with exact paths cited.

Research receipt: local-corpus, GitHub, live-product and operator/market research is recorded below. Every cited GitHub repository has a same-day gh api repos/OWNER/NAME receipt; every NOASSERTION row has an actual license-source inspection below. The candidate labels are rankings for evidence/proof work, not adoption claims.

Deep research receipt — 2026-08-29

Method and corpus boundary

The local corpus was queried read-only. The identity database at /Users/shaansisodia/SISO_Workspace/SISO_Agent_Base/research/repo-catalog/identity/identity.sqlite contains 1,358,200 repo_card rows. The curated database at /Users/shaansisodia/SISO_Workspace/SISO_Research/siso-foundry/pipelines/github/awesome/catalog_full.sqlite contains 307,180 repositories, 652,851 entries and 4,026 lists. The curated bank is a peer/editorial signal, not a quality or adoption verdict.

The targeted curated-entry counts were: creator 396, influencer 14, talent 38, onboarding 109, consent 40, rights 64, contract 1,329, offboarding 1, portal 311, e-signature 13 and authorization 444 distinct target repositories. The bank's peer-validated search returned NOT FOUND for the narrower phrases creator management, talent management and content rights; it returned generic authorization libraries for access control, and documenso/documenso/docusealco/docuseal for e-signature. This is a useful negative: lexical breadth is not evidence of an OFM creator-lifecycle product.

The identity snapshot contains several of the candidates below, but its stored stars and push dates are a June snapshot. Current stars, license metadata, branch and liveness in this file come from the gh api receipt, not from stale corpus fields. GitHub discovery used gh search repos for creator CRM, talent management CRM, creator onboarding portal, consent rights management, e-signature, joiner/mover/leaver and creator outreach, then narrowed to repositories whose README exposed a lifecycle-relevant primitive. The discovery funnel is seed evidence; the ledger below is the verification boundary.

The web pass used official product/developer documentation where available, product pages as vendor claims [VC], and operator material as operator signals [OP]. No vendor metric is treated as validated adoption. No direct OFM interview was found in this pass. No public or private source proved a Camron model app or deployment; that remains [U].

Ranked system donors — separate from sidecars

These are systems or broad shells that could inform a re-platform experiment. None is allowed to become creator, consent, contract, credential, money or referral authority by reputation alone. The rank is domain fit × inspectability × composition risk, not GitHub stars.

System-donor composition conclusion

No broad donor closes the domain gap. Open Mercato is the only first spike with a clean permissive headline license and explicit portal/tenant/custom-entity primitives, but that is not a reason to move authority out of HALO. Huly and erxes demonstrate breadth with continuity or license boundaries. Twenty and Comp AI CRM offer useful relationship/agent patterns. The minimum safe experiment is a read-only synthetic comparison of entity, permission, audit, export and webhook semantics; it is not a parallel production source of truth.

Ranked specialist sidecars and focused code donors

Talent / creator CRM and acquisition

Consent, privacy and rights

No verified open-source repository in this pass provided a purpose-built adult-creator consent/likeness/rights ledger. That is a genuine missing category, not permission to model consent as a boolean on creators or to copy a generic cookie-consent package.

E-signature and contract evidence

External portal, JML/access and offboarding/export

For commercial access lifecycle, WorkOS Directory Provisioning ↗ and Okta Lifecycle Management ↗ are useful [VC] JML benchmarks: deprovisioning should make a membership inactive/revoked without destroying its audit identity, and re-provisioning should be an explicit event. The same principle belongs in creator and staff offboarding, but those services must not silently own HALO creator records or export policy.

Ranked live-product and private-operator benchmarks

These are current public product claims or private/in-house signals, not verified adoption, customer outcomes or legal compliance. They answer “what should we compare in a demo or interview?” rather than “what should HALO import?”

Specialist vendor comparison by prerequisite

Operator evidence and vocabulary

The operator pass supports a control loop, not a feature shopping list. The most reusable OFM-specific vocabulary is creator-specific voice training; synthetic/dummy fans; trial shift, nesting and shadowing; playbook versus agency SOP; shift handoff; weekly QA/calibration; retraining; fan segmentation and retention. CreatorHub's operations guide ↗ describes handoff fields such as active conversations, promises owed, VIP notes, flags and what was sent, then connects voice definition to sampled QA and coaching. OnlyFans Course's team/SOP library ↗ is another vendor/course signal for tone calibration, shift protocols, creator-specific context and assignment-scoped access.

Use these signals to design a synthetic operator proof: a new chatter practices against dummy fans, shadows a shift, receives a creator-specific playbook, produces a required handoff, gets weekly calibration, and is retrained from QA findings. The system must log which playbook/version and which boundaries were active; it must not send a live message or make a real fan/creator decision in this proof.

The X/DSA diagnose → practice → observe → audit → coach → refresh loop is a generic control-loop inference [I], not OFM evidence, and is deliberately not used as proof of market prevalence. Vendor metrics and testimonials remain untrusted until direct operator interviews or reproducible trials.

Final composition boundary

The proposed system is a trust passport around a creator relationship, not a universal CRM and not a credential warehouse:

HALO / creator lifecycle authority
  creator ID + provenance + candidate/roster state
  contract/term versions + economics + referral attribution
  consent/rights scope + evidence status/reference + expiry
  capability readiness passport + owners + holds + revoke path
  access grants + credential references + Drive/assets + statements
  renewal, incident, termination, export and append-only proof receipts

Specialist adapters (opaque, purpose-limited)
  KYC/age provider  -> result/reference/expiry/review, never raw identity authority
  e-sign provider   -> envelope/document/audit/certificate references
  vault             -> opaque secret reference and rotate/revoke receipt
  access/JML        -> grant/revoke outcome, not creator identity ownership
  portal            -> scoped projection over HALO, never a second roster

Buzz / collaboration and event plane (fixed)
  handoff, reminder, approval request, notification, agent session and deep link
  no creator/contract/consent/credential/money mutation; no raw sensitive payloads

The passport's readiness predicate is explicit:

ready(creator, capability) =
  active_contract_version
  AND consent_scope_covers(capability)
  AND evidence_passed_for_purpose_and_subject
  AND every_required_expiry_is_future
  AND access_grant_is_scoped_and_active
  AND named_owner_exists
  AND revoke_path_exists
  AND no_active_hold

Every transition should emit a human-readable receipt containing stable creator/capability IDs, actor, source, timestamp, term/evidence/access versions, expiry, owner, reason and revoke path. A provider callback can propose a transition; only the HALO authority can make the transition. A missing, stale, conflicting or unverifiable prerequisite is hold, not “probably active.”

The proposed Buzz link is an idempotent, scoped halo://creator/{id} resource reference. Buzz can carry a handoff or approval request; the receiver must reopen HALO to see the authoritative state. This preserves the fixed collaboration plane and prevents a message, agent session or vendor dashboard from becoming a shadow lifecycle database.

GitHub verification and license ledger

The following values are fresh gh api repos/OWNER/NAME receipts collected on 2026-08-29. Stars are a volatile discovery signal, not quality evidence. NOASSERTION is GitHub API metadata, not a license verdict; the actual source inspection is listed after the table.

Actual NOASSERTION license-source inspections

• erxes LICENSE.md ↗: content

outside ee is AGPLv3; enterprise plugins use ee/LICENSE; the root text says erxes cannot be hosted as a SaaS competing with erxes Inc.

• Twenty LICENSE ↗: most code is

AGPLv3; files marked @license Enterprise are commercial; named SDK/UI/app packages can be MIT; the application exception covers applications interacting through published interfaces, not modifications to Twenty itself.

• OpenCATS LICENSE.md ↗:

OpenCATS code is MPL-2.0 while original circa-2007 CATS code is under a separate CATS Public License 1.1a.

• OpenSign LICENSE ↗:

content outside the listed custom-route directory is AGPLv3; third-party components retain their original licenses.

• IdentityLifecycleEngine LICENSE.md ↗:

the actual root text is Apache License 2.0, explaining why GitHub returned NOASSERTION.

• Directus license ↗: actual source

is Monospace Sustainable Core License, MSCL-1.0-GPL; it defines competing use and limitations, so NOASSERTION must not be read as permissive.

The non-NOASSERTION rows were also read through gh api metadata. The ledger intentionally does not cite a repository whose current metadata or source was not independently checked.

Reject ledger and negative findings

HALO-specific blocker set that remains in force

The read-only clone review still shows: creator onboarding is a multi-step data form rather than a verified evidence flow; invitation expiry is undefined; contract signing has no visible tamper-evident version/expiry/revocation ledger; accept provisions a temporary password from a hard-coded value; social-login records include plaintext credentials; client-side local storage and role checks do not establish server authorization; /upload/:id is not visibly wrapped by ProtectedRoute and uses legacy Supabase storage; Drive provisioning lacks rights/takedown lineage; and no dedicated creator home exposes readiness, rights, statements, export or revoke. These are findings from the inspected source, not claims that every path is reachable in production. They are enough to block autonomous activation, not to justify a new product shell before the authority contract is designed.

Synthetic proof plan — before any live pilot

No live account, credential, Convex mutation or deployment is needed for the first proof. Use fake names, fake provider references, fake signatures, dummy fans and a local deterministic event fixture. The proof should be a testable contract/eval harness, not a screenshot.

Proof acceptance gates

Do not call the composition ready until all of the following pass with synthetic data:

1. No capability reaches active without contract, consent, evidence, access, owner and

revoke prerequisites.

1. Expiry, withdrawal, hold and staff-leaver events prevent consequential actions even when

a stale portal, Buzz message or provider callback is replayed.

1. Every sidecar callback is authenticated, subject-bound, idempotent and exportable; sidecar

outage leaves HALO usable and creates an owned exception.

1. Creator, manager, chatter, finance, compliance, referral and Buzz views are least

privilege and server-authorized; no raw identity or secret appears in collaboration logs.

1. A double-run offboarding produces one complete export/revoke receipt, not two payouts,

two revokes, lost audit history or a deleted creator record.

1. A claimed model app cannot advance past [U] without direct repository/deployment proof

and the same read-only identity/permission/export/revocation probe.

This is the smallest proof that can falsify the trust-passport thesis before HALO is asked to own more sensitive data or before any vendor receives real creator information.