CREDITUNION.DEV PLATFORM NARRATIVE

One kernel. One member journey. Every channel connected.

A complete credit union operating platform where public marketing, onboarding, member experience, omnichannel support, and employee operations are all driven by one governed kernel.

Configuration matrix →CU OS shell →Marketing CMS →

CREDITUNION.DEV is the platform and architecture layer.

CU OS is the Rust kernel that governs the system.

CU.APP is the member application that runs on top of it.

The Member Advocate Portal is the employee operating surface.

Every surface is content-driven, config-driven, and connected by one kernel.

Omni-Channel Journey Diagram

Technical version

flowchart TD
    A[Public Marketing Website] --> A1[CMS / Content Ops]
    A --> A2[Product Catalog / Product CMS]
    A --> A3[Rates / Eligibility / Disclosures]
    A --> A4[SEO / Campaign Pages / Landing Pages]
    A --> B[Member explores products]

    A1 --> K[CU OS / Config + Content Kernel]
    A2 --> K
    A3 --> K
    A4 --> K

    B --> C[Product Detail Page]
    C --> D[Apply / Join / Open Account]
    D --> E[Onboarding Flow]
    E --> E1[Identity / KYC / OFAC]
    E --> E2[Fraud / Device / Risk]
    E --> E3[Consent / Disclosures / E-Sign]
    E --> E4[Funding / Account Opening]
    E --> E5[Username / Passkey / Member Claim]
    E5 --> F[CU.APP Member App]
    E4 --> F

    F --> G[Need help?]
    G --> H[Omnichannel Routing Layer]
    H --> H1[In-App Messaging]
    H --> H2[Secure Message]
    H --> H3[Email]
    H --> H4[SMS]
    H --> H5[Push Notification]
    H --> H6[Voice / Phone]
    H --> H7[Call Center IVR]
    H --> H8[Branch / Appointment / Case]
    H --> H9[AI + Human Handoff]

    H1 --> I[Member Advocate Portal]
    H2 --> I
    H3 --> I
    H4 --> I
    H5 --> I
    H6 --> I
    H7 --> I
    H8 --> I
    H9 --> I

    I --> I1[CRM / Member 360]
    I --> I2[Case Management]
    I --> I3[Fraud Review Queue]
    I --> I4[Disputes / Card Support]
    I --> I5[Knowledge Base / Employee Manual CMS]
    I --> I6[IVR Flow Builder]
    I --> I7[Announcements / Internal Comms CMS]
    I --> I8[Config Approval / Release Center]
    I --> I9[Journey Replay / Audit Timeline]

    I5 --> K
    I6 --> K
    I7 --> K
    I8 --> K

    K --> J[CU OS Rust Kernel]
    J --> J1[Config Resolution Engine]
    J --> J2[CMS / Content Registry]
    J --> J3[Product / Offer Registry]
    J --> J4[Identity Graph]
    J --> J5[Onboarding Orchestrator]
    J --> J6[Fraud Signal Engine]
    J --> J7[Omnichannel Event Bus]
    J --> J8[Adapter Runtime]
    J --> J9[Audit / Evidence / Proof Engine]
    J --> J10[Release / Fork / Compatibility Engine]
    J --> J11[Flutter App Generator / Build Orchestrator]

    J8 --> L[Core / PowerOn / Symitar / Corelation / DNA / Cards / ACH / Bill Pay]
    J7 --> M[Analytics / AI / Notification Providers]
    J11 --> N[Branded CU.APP Builds]
    N --> F

Simplified System Proof

Executive version

flowchart LR
    A[Marketing Site + CMS] --> B[Product Discovery]
    B --> C[Onboarding]
    C --> D[CU.APP Member Experience]
    D --> E[Omnichannel Support]
    E --> F[Member Advocate Portal]
    F --> G[Employee Manual + Internal Announcements CMS]

    A --> H[CU OS Rust Kernel]
    B --> H
    C --> H
    D --> H
    E --> H
    F --> H
    G --> H

    H --> H1[Config Engine]
    H --> H2[CMS / Content Engine]
    H --> H3[Identity + Product Graph]
    H --> H4[Fraud + Policy Engine]
    H --> H5[Adapter Layer]
    H --> H6[Audit + Release Engine]

    H5 --> I[Core Systems / Vendors]
    H6 --> J[Private Federated Forks]

System Decomposition by Layers

Experience Layer

Marketing website, CU.APP, Member Advocate Portal, internal announcements.

Domain Control Layer

Product registry, onboarding orchestration, case routing, fraud decisions, messaging policies.

CMS + Config Layer

Marketing CMS, Product CMS, disclosures, employee manual CMS, announcements CMS, IVR content.

CU OS Rust Kernel

Config resolution, contract validation, compatibility enforcement, adapter orchestration, event contracts, audit proofs, release governance, Flutter build orchestration.

Integration Layer

Symitar, PowerOn, Corelation, DNA, cards, ACH, bill pay, KYC, docs, notifications, analytics, AI.

Federation Layer

Private sovereign tenant forks with shared interoperability protocol guarantees.

End-to-End Member Journey

1. Attract

Marketing edits homepage, campaigns, featured products, rates, FAQs, and disclosures in CMS.

2. Discover

Members see configured product cards from the product registry across web and app channels.

3. Decide

Members choose checking, loan, card, membership, business account, or refinance offers.

4. Onboard

The same orchestrator runs eligibility, docs, disclosures, consent, KYC/OFAC, fraud checks, funding, and account creation.

5. Activate

Username/passkey sessions modernize access while preserving legacy core identity compatibility.

6. Use

Members navigate accounts, transactions, transfers, cards, bill pay, alerts, messaging, and fraud protection.

7. Need Help

Conversations continue across chat, secure message, SMS, email, IVR, call center, and branch without losing context.

8. Advocate Assist

Advocates see timeline, case state, fraud signals, onboarding status, and prior interactions in one portal.

9. Internal Knowledge

Employee manual CMS and announcements CMS are embedded directly inside the portal workflow.

10. Improve

Marketing, ops, risk, and support teams ship governed updates through a single release model.

Proof Checklist (10 Things To Demonstrate)

One product created in CMS appears on website, onboarding, app, and advocate portal.

One member starts on website and continues through onboarding, account creation, app login, and support.

One identity persists across marketing lead, applicant, app user, IVR caller, and advocate case.

One conversation persists across app chat, secure message, SMS, IVR, phone, and employee portal.

One employee works from one portal with Member 360, case context, fraud context, and onboarding context.

One fraud signal appears in member and employee experiences with proper redaction.

One config change alters behavior across disclosures, eligibility, IVR route, and app feature flags.

One release model governs draft, validate, approve, publish, observe, and rollback.

One adapter layer connects legacy systems without leaking raw core schemas into UI.

One Rust kernel ties config, contracts, events, adapters, fraud, builds, and proofs.

What this proves

To prove this system is real, the demo must show all surfaces connected by one governed kernel rather than separate demos. The audience should see one control plane, one identity graph, one content and product family, one fraud/risk model, one adapter layer, one release model, and one federated interoperability protocol.

CREDITUNION.DEV = platform layer | CU OS = Rust kernel | CU.APP = member app