External Systems¶

Executive Summary¶

External Systems defines the systems, authorities, data sources, channels, and partner platforms that sit outside the Algosure system boundary in the C4 Level 1 context.

Why This Exists¶

Algosure depends on external tender sources, compliance authorities, collaboration platforms, payment services, funding partners, and marketplace providers. These systems must be represented as external dependencies so architecture can preserve ownership, security, tenant isolation, and integration governance.

Owner¶

The owner is the Chief Product Officer and Enterprise Architect.

Business Value¶

Identifying external systems early reduces integration ambiguity, prevents accidental source-of-truth duplication, and clarifies which parties control availability, data correctness, policy, and commercial terms.

External System Context¶

flowchart LR
    subgraph Sources["Tender Sources"]
        PublicTender[Public Tender Sources]
        PrivateTender[Private Tender Sources]
    end

    subgraph Authorities["Government and Compliance Authorities"]
        SARS[SARS]
        CIPC[CIPC]
        CSD[CSD]
        CIDB[CIDB]
        COIDA[COIDA]
        BBBEE[B-BBEE Agencies]
        FutureGov[Future Government and Country-Specific Integrations]
    end

    subgraph Collaboration["Productivity and Collaboration"]
        Gmail[Gmail]
        Outlook[Outlook]
        Drive[Google Drive]
        OneDrive[OneDrive]
        DocuSign[DocuSign]
        WhatsApp[WhatsApp]
    end

    subgraph Partners["Commercial Partner Ecosystem"]
        Payment[Payment Provider]
        Funding[Funding Partners]
        Marketplace[Marketplace Providers]
    end

    Algosure[Algosure System]

    Sources --> Algosure
    Authorities --> Algosure
    Collaboration <--> Algosure
    Partners <--> Algosure

External System Catalogue¶

External System	Category	Context Relationship
Public tender sources	Tender source	Provide public opportunity signals, tender notices, documents, deadlines, amendments, and award information.
Private tender sources	Tender source	Provide restricted or invite-only opportunity signals, documents, clarifications, and submission requirements.
SARS	Government and compliance authority	Provides tax-related compliance status, obligations, and validation context where authorized.
CIPC	Government and compliance authority	Provides company registration, director, and business identity context where authorized.
CSD	Government procurement authority	Provides supplier registration, procurement eligibility, and central supplier information where authorized.
CIDB	Industry authority	Provides construction industry registration, grading, and contractor eligibility context where relevant.
COIDA	Compliance authority	Provides compensation and workplace compliance evidence where relevant.
B-BBEE agencies	Compliance authority	Provide B-BBEE certificate, affidavit, verification, level, and expiry context.
Gmail	Email platform	Provides email communication context and may receive approved outbound communication where authorized.
Outlook	Email platform	Provides email communication context and may receive approved outbound communication where authorized.
Google Drive	Storage platform	Provides document storage and retrieval context where authorized.
OneDrive	Storage platform	Provides document storage and retrieval context where authorized.
DocuSign	Signature platform	Supports external signature workflows and signed document evidence where authorized.
WhatsApp	Messaging platform	Supports approved communication, notifications, and evidence capture where authorized.
Payment provider	Commercial provider	Supports billing, subscription, payment, refund, and commercial transaction context.
Funding partners	Commercial partners	Support funding qualification, funding offers, application evidence, decisions, and status updates.
Marketplace providers	Commercial partners	Support supplier discovery, quotes, product or service availability, and marketplace transaction context.
Future government and country-specific integrations	Expansion systems	Represent future authorities, registers, tax bodies, procurement portals, identity services, and compliance systems outside South Africa.

Ownership Rules¶

Rule	Meaning
External systems remain authoritative for their own facts	Algosure may store evidence, derived state, or verified snapshots, but the external authority or provider controls the originating system.
Domains own Algosure interpretation	Internal interpretation, readiness state, workflow state, recommendations, and events must map to the owning Algosure Domain.
External access is tenant-bound	Integrations must operate under authorized tenant context, consent, scope, and audit.
Events represent business meaning	External changes should be translated into domain-owned business events where they affect Algosure workflows.
Contracts precede implementation	Each external system requires explicit contract design, error handling, retry, consent, privacy, security, and support ownership before implementation.

Risk Context¶

Risk	Architecture Response
External availability changes	Algosure must separate external dependency status from internal domain ownership and workflow recovery.
External data may be stale or incomplete	Algosure must preserve evidence timestamps, source attribution, confidence, and validation state.
External terms and policies may change	Integrations require governance and review ownership.
Country-specific variation	Future integrations must be modeled as external capability extensions without weakening core Domain boundaries.

Non-Implementation Boundary¶

This document does not define:

Integration protocols.
Provider selection.
API contracts.
Webhook behavior.
Sync schedules.
Data mapping fields.
Error codes.
Commercial agreements.