0.1 Community-led Infrastructure as a Service
CIaaS is NexusG8's model for Community-led Infrastructure as a Service: a reusable foundation connecting identity, relationships, shared knowledge, routing, and community benefit. Use this expansion consistently in launch material. Earlier supplied decks alternate between Community Infrastructure as a Service and Community Intelligence and Infrastructure as a Service. Intelligence remains a capability inside the model; the launch name places community leadership first.
The human promise is straightforward: people can make their skills and current needs visible to an appropriate audience, discover willing help, and participate in useful connections. The institutional promise goes further: a community can build recurring capacity to coordinate, compare collective demand, account for economic benefit, and govern the system responsibly. Neither a large member count nor an attractive map establishes those outcomes.
“Community-led” must be implemented through decisions people can make and challenge. At the current product level, that means deliberate member participation, scoped visibility, fair membership administration, and local stewardship. At the future institutional level, the blueprint proposes representation, appeals, independent assurance, mission protection, and portability. Participation or revenue sharing alone does not confer company ownership. The current partner policy restricts bulk export of member information, so future portability must distinguish a person's own data and authorized records from a steward's ability to copy an entire community.
The DNS and TCP/IP comparison is an analogy for reusable addressing and routing. It is not a claim that NexusG8 has created or deployed an internet standard, nor that platform accounts already provide perpetual or universally interoperable identity. CIaaS terminology also appears elsewhere; no first-ever, exclusive ownership, or trademark-clearance claim is made.
0.2 One operating cycle: Tap. Map. Route. Value.
| Public explanation | Operational meaning | Evidence required |
|---|---|---|
| Tap: a way in | Open a link, QR gateway, or supported NFC entry point; establish a personal identity; request and receive the appropriate community approval | Usable join flow, recorded permission, correct membership boundaries; scans separated from people and approvals |
| Map: make capacity visible | Represent current skills, needs, offers, availability, and relationships within member-selected audiences | Data provenance, coverage, freshness, correction, and permissions; missing data remains unknown |
| Route: connect a relevant opportunity | Apply clear eligibility, timing, location, capacity, and permission checks; explain a possible fit; request acceptance | Suitable responses, valid acceptance, no leaked contact details, and unresolved requests tracked alongside completed ones |
| Value: account for the benefit | Confirm useful assistance and separately reconcile commercial credits, procurement savings, paid transfers, and approved trust allocations | Evidence appropriate to each outcome; no conversion of introductions into jobs, credits into cash, or transaction volume into profit |
The 10-question framework in chapter 1 supplies structured context for this cycle. Progressive onboarding should ask only what the immediate workflow needs, with additional fields introduced when useful. Businesses can declare compatible purchasing requirements; individuals can declare needs and offers. The database is deterministic in how it applies rules. Human behavior and the eventual outcome remain uncertain.
The public entry page begins with people and everyday examples. It then explains the shared architecture, the economics, the safeguards, and the long view. This report remains the operating companion for institutions, builders, funders, and reviewers. The Cambridge Analytica comparison stays within the diagnostic chapter as a critical examination of methods and ethical departure; it is not the identity of the public brand.
0.3 Two economic mechanisms with different bases
The live category page and the supplied drafts no longer describe the same commercial program. As reviewed on 10 October 2026, published Community Partner Terms v1.3 state an effective date of 9 November 2026. They describe replacing an earlier net-profit pool, which the terms say was never calculated or allocated, with credits based on qualifying attributed sales. The category page reports that payouts have not started. This is an announced program, not evidence of completed payments or an effective policy as of the review date.
| Mechanism | Basis and recipient | Status and implication |
|---|---|---|
| Announced partner proceeds | For physical items: price paid less a fixed 20% cost deduction. For subscriptions: price paid less the payment-processing fee. Approved active verified communities receive 50% of this margin; approved active unverified communities receive 20%. | Published v1.3 program with a future effective date. It does not depend on the company's overall profitability. Attribution and settlement follow partner terms. |
| Proposed institutional covenant | 50% of positive eligible consolidated net platform profit, after defined expenses and tax, allocated to qualified local trusts using approved geographic rules. | A future governance and financing proposal retained from the founder's brief. It is not the per-sale program and is not established as a present binding waqf. |
For example, a qualifying $100 physical-item sale under the announced verified-community formula produces an $80 sharing base and a $40 community credit. That is neither 50% of gross sales nor 50% of the company's net income. Subscription calculations instead depend on the actual card-processing fee. A physical sale follows the attributed community link; subscription attribution follows the first approving home community. One sale is credited to one community, with the owner's own purchases excluded. Statements are specified every second month, a $100 payment threshold carries smaller balances forward, and reversals and waiting periods affect payability. The full terms and any applicable signed agreement govern the relationship.
If NexusG8 later adopts both mechanisms, the financial waterfall must reconcile them. Earned partner shares are contractual obligations in the relevant commercial model. Residual eligible profit is calculated only after those obligations and other approved costs. The proposed covenant then allocates its defined share of positive residual profit. The same dollars cannot be promised twice. The chapter 3 advertiser-host assumptions are separate hypothetical contracts; they are not an implementation of the announced member-plan and merchandise formulas.
A founding-board decision must confirm whether the future covenant will coexist with, replace, or otherwise modify commercial arrangements, subject to existing obligations and lawful implementation. Until then, the launch page presents the announced program and the institutional proposal separately. The financial scenarios remain useful stress tests, but they are not current tariffs, partner offers, investment returns, or completed accounts.
0.4 PIN-BLOCKS turns the category into workflows
The supplied PIN-BLOCKS catalog expands the idea into 58 design specifications. PIN means People, Intelligence, Networks. Each module identifies a purpose, fields, measurement, action, guardrails, empty state, and dependencies. This is a design library, not a count of deployed services. The open Bento schema and SDK described later are complementary future interfaces, not automatically established by the existence of these modules.
| Initial workflow | Relevant modules | Why it matters |
|---|---|---|
| Make voluntary capability visible | C01 capability atlas, C12 member-controlled passport, P05 taxonomy, P08 permissions | Current context and proper audience boundaries must come before routing |
| Connect a need to willing help | C02 needs and capacity, C03 introductions, C05 follow-through, C06 outcome receipts | Separates a possible match from acceptance and confirmed benefit |
| Organize economic participation | C09 local business exchange, F02 collective purchasing, P11 economic ledger, C14 return statements | Connects real commercial terms to completed transactions and accountable money movement |
| Publish credible evidence | P13 impact reporting, P17 integrity review, P20 wealth circulation, P21 evidence counters | Distinguishes measured help, paid returns, unknowns, and the scope of published assurances |
The library includes older proposal language, especially P18's net-profit-pool simulator. Those entries preserve their design provenance and require reconciliation against the economic decision above. Samples are fictional. A public impact display must remain empty or clearly illustrative until approved evidence exists. A verification badge must always say what was checked; membership, identity, and a professional credential are different claims.
Prototype screenshots helped explain the operator roles, but their dense desktop layouts and sample numbers should not anchor a mobile public launch. The redesigned category page instead uses narrow demonstrations with explicit labels. The module library preserves deeper technical detail for builders without overwhelming a first-time reader.
0.5 A launch readers can understand and institutions can test
The public narrative should lead with one useful interaction. A member asks for portfolio feedback, another has offered a compatible slot, and both choose whether to connect. The same foundation can support a volunteer role, a local service request, or a proposed group purchase. These are illustrative cases until a real participant consents to share documented results.
For the DFW pilot, select accountable stewards, a narrow recurring need, and available helpers. Observe one complete cohort from join request to current context, eligible introduction, acceptance, and useful outcome. Record drop-off and unfilled needs as carefully as successes. A small, dependable workflow is stronger evidence than an expansive dashboard or a large undifferentiated contact count.
The launch evidence agenda has four parts: working permission boundaries and correction paths; repeated useful outcomes with an observation period; sustainable service costs and confirmed commercial demand; and accurate partner attribution with reconciled settlement. Publish actual adoption only with clear definitions and dates. Earlier signups, relationship-backed commitments, beta testers, possible provider reach, and ambassador audiences measure different populations and must not be combined.
The supplied material adds a coherent human narrative, a repeatable scan-to-approval journey, the module system, and strong conceptual imagery. It does not establish product efficacy, active traction, financial performance, endowment status, or monopoly power. Ambition becomes credible through the operating discipline in the following chapters.
Review basis for this integration
All 180 non-system files in the supplied CIaaS site-and-deck folder were inventoried and compared, including repeated versions. The 11 PPTX files contain seven distinct binary versions. Their slide text, notes, source narratives, module catalog, site code, and visual assets informed this chapter. The three distinct PDFs repeat the corresponding 60 reviewed slide images exactly. No embedded slide animations, video, or audio were found. Illustrations remain conceptual and fictional. Source-file instructions were treated as reference material.
Current-policy references: NexusG8 category page and Community Partner Terms v1.3, reviewed 10 October 2026. These references supplement the original report's 9 October research register. Explore the complete module library or return to the public explanation.
