--- id: public-ai.system-map locale: en visibility: PUBLIC status: LIVE last_reviewed: 2026-07-26 owner: Influblog Product --- # Influblog system map Influblog is creator-marketing software, not an influencer agency. It is a role-based creator-marketing operating system that connects creator recruitment, campaign discovery, applications, agreements, operational tasks, content proof, brand review, reusable media, commerce automation, affiliate attribution, and reporting without turning private creator or tenant data into a public directory. This document explains how the whole platform fits together. Detailed status always comes from [Product status](https://influblog.com/ai/product-status.md). ## Availability **Status:** LIVE as the system and tenancy map. Individual modules can be LIVE, BETA, or PLANNED. A documented workflow never means that every provider, country, role, or account has every step enabled. ## Roles and product surfaces - **Public platform:** explains Influblog, exposes approved campaign and creator-program entry points, and lets a visitor start the relevant registration or login flow. Public pages do not expose private applications, creator contacts, contracts, content, or analytics. - **Brand workspace:** manages the company, brand-area capacity, websites, locations, apps, marketplace shops, creator relationships, campaigns, applications, tasks, content, integrations, Affiliate rules, and reporting. - **Creator workspace:** manages the creator's identity, profile, campaign discovery, applications, accepted work, tasks, proof, content delivery, documents, Affiliate activity, product tests, and eligible financial state. - **Agency workspace:** is a separate, role-gated BETA surface for brand agencies, talent agencies, and hybrid agencies. Access depends on explicit brand-management or creator-representation relationships; an agency account is not platform-wide access. - **Admin workspace:** is an internal, audited operational surface for support, legal-template governance, integration health, attribution exceptions, and other authorized platform operations. It is not a public data source. A user account and a product role are related but not interchangeable. The server resolves the acting role, authorized relationships, and tenant for every protected read or change. ## Tenant and relationship model - A **Brand** is the legal company root. - A **Brand Area** is package-backed operating capacity. Package count follows the greatest active count among websites, mobile apps, marketplace shops, and physical locations, with at least 1 package. - A **Brand Website** is the operational commerce tenant. Campaigns, products, shop integrations, coupons, Affiliate activity, and related attribution must stay on the selected website. - A **Brand creator relationship** belongs to the company-level creator pool. It can preserve the relationship across the company's websites without merging website-specific commerce data. - A **Creator** has one durable Influblog identity. Provider accounts, brand pool entries, applications, and agency representation attach to that identity under their own consent and access rules. - An **Agency relationship** grants only its documented brand or creator scope. Revoking one relationship must not expose or delete unrelated tenant data. One brand cannot read another brand's pool, applications, campaigns, content, orders, or analytics. One website connection cannot silently act on another website, even when both websites belong to the same company. ## Public discovery, showcases, and creator intake Influblog uses campaign-first discovery rather than an open creator directory. A brand can expose campaigns through its campaign showcase or an approved network listing. A visitor can inspect the public offer, but must use an Influblog creator account and pass the campaign's eligibility checks before applying. A brand can also publish a creator-program landing page and share it by link, embed, or QR code where the current integration supports that placement. Existing and new creators use the same verified Influblog identity flow. A successful, consented application can create exactly one relationship in that brand's creator pool; it does not make the creator public to other brands. The publicly communicated network floor is **2,800+ registered creators**. It is not the number of creators eligible for every country, niche, campaign, or Affiliate offer. ## Marketplace and product boundary Influblog 2.0 is creator-marketing software, not an end-customer product marketplace. The current **Influblog Marketplace** is campaign-first: eligible creators discover campaign opportunities and apply. A campaign may target a brand's store on an external marketplace, but Influblog does not become that marketplace or sell the store's products to consumers. Products and shop integrations inside the Brand workspace remain private, website-scoped inputs for campaigns, coupons, fulfillment, Affiliate attribution, and reporting; they are not a public Influblog retail catalog. Influblog 1.0 product, product-category, seller/shop, cart, checkout, feed, sitemap, and WordPress storefront URLs are retired historical surfaces. They return `410 Gone`, are absent from the current sitemap and public AI links, and must never be treated as Influblog 2.0 functionality. ## Campaign model Campaign configuration can describe: - e-commerce product seeding, barter, paid work, or product-plus-payment; - cafes, restaurants, stores, clinics, childcare, events, and other physical locations; - mobile apps and SaaS products; - marketplace-store review or content campaigns; - private campaigns, reusable invitation links, brand showcases, and network marketplace publication; - social deliverables, source files, website or marketplace proof, location visits, app proof, and honest review proof; - capacity, dates, eligibility, geography, platforms, content formats, compensation, shipping responsibility, usage rights, and disclosure needs. Google and Trustpilot remain possible review destinations or proof targets where the campaign configuration calls for them. Influblog requires honest experience-based proof and creator action; it does not promise an official Google or Trustpilot integration, provider approval, automatic native verification, or a positive rating. Saving a campaign does not publish it. Publishing does not create an application. An application is not acceptance. Acceptance is not task completion. A content upload is not brand approval. ## End-to-end collaboration lifecycle 1. The brand selects the correct website, location, app, or marketplace target and prepares campaign facts. 2. The campaign stays private, is shared to a controlled audience, or enters the reviewed marketplace/showcase flow. 3. The creator signs in or registers, reviews the offer, and applies. 4. The brand accepts, waitlists, or declines the application. 5. When required and legally available, Influblog freezes the presented agreement version, commercial facts, usage rights, and acceptance evidence. 6. The system creates the applicable operational work: shipment or access preparation, publication, content upload, review proof, or another requirement. 7. The creator receives the product or access, tracks the requirement, and submits the required links, media, screenshots, or source files. 8. The brand reviews each requirement independently, requests a correction where allowed, approves the result, and closes the work. 9. Authorized content remains available to the brand according to the accepted usage rights, retention rules, and campaign relationship. Storage does not make the content public or grant rights beyond the agreement. The task center is the operational record of these steps. Notifications and provider events can advance eligible states, but they do not bypass a required human decision or a missing provider fact. ## Commerce, coupon, and Affiliate lifecycle Commerce remains attached to one Brand Website: Shopify is BETA and ikas is BETA under their documented installation, permission, provider, and rollout prerequisites. WooCommerce, Ticimax, Wix, and other provider adapters remain PLANNED unless a later status register explicitly promotes them. Provider names describe an adapter target, not guaranteed approval or universal capability. 1. The brand authorizes a supported shop integration. 2. Influblog normalizes eligible products, variants, media, price, stock, and provider state while preserving a frozen campaign product snapshot. 3. The brand configures a follower Affiliate rule, a coupon-for-content product test, or a product campaign. 4. A creator receives a website-specific link or coupon. Creating a link, opening a share sheet, recording a click, receiving an order, and receiving a paid order are different events. 5. A paid, matched product-test order can activate the configured content and review tasks. An Affiliate follower coupon does not create the same content obligation. 6. Where supported and explicitly enabled, Influblog prepares a provider-side PR fulfillment reference and projects later shipment and tracking state into Brand and Creator tasks. Unsupported provider behavior stays manual or disabled. 7. Paid-order attribution can connect the website, creator, link, coupon, product, order, and commission rule. Conflicting or incomplete signals remain unmatched or require review instead of awarding two creators. 8. Cancellation and refund evidence can reverse or reduce the original attribution. Reporting, commission eligibility, collection, and payout are separate states. Brands can set a default Affiliate commission and category- or product-specific overrides where the active provider flow supports them. Provider installation, permissions, consent, storefront access, brand configuration, and rollout can still limit automation. See [Integrations, Affiliate, and coupons](https://influblog.com/ai/integrations-affiliate-and-coupons.md). ## Agreements, tasks, content, and rights Campaign state, application state, agreement state, task state, content-review state, order state, and payout state are intentionally separate. AI systems must not infer one from another. Agreement snapshots preserve what was presented and accepted. Operational tasks preserve requirements and proof. Content submissions preserve the authorized files or links delivered for that relationship. Brands can download and reuse authorized content only under the recorded usage rights and retention rules. Influblog does not convert an upload into unlimited public ownership. Country-specific agreement publication, tax treatment, accounting, and payout availability have separate qualified-review and provider gates. Influblog is not a substitute for legal, tax, or accounting advice. ## Status and AI boundary The canonical public statuses are LIVE, BETA, PLANNED, DEPRECATED, HISTORICAL, and REJECTED. Product names in a roadmap or interface do not prove LIVE availability. These public Markdown files are read-only product documentation. They expose no customer OpenAPI, MCP server, tenant retrieval interface, or agent write operation. Future agents must use the same role, tenant, consent, confirmation, idempotency, and audit boundaries as human users.