Product catalogue

What Klarum actually ships, module by module. This page reads the same versioned artifact the gateway serves at /api/catalog, so what you see here is what the product is built against rather than a summary written about it.

What is in the catalogue

Modules
18
Capabilities
99
Engines
9
Integrations
23

How Klarum fits together

What Klarum is

Klarum is a full-stack infrastructure-project screening and bid-management platform built by Klarum for consultancies and contractors that chase public-sector and development-bank work. Its spine is a two-sided deal-flow funnel running over one shared opportunity/knowledge substrate:

  • Outbound (supply-side hunt): Klarum ingests public tenders and aid-funded opportunities from around the world, understands them in plain language, and tells each firm which ones are worth bidding on, then converts a chosen tender into a full bid workspace.
  • Inbound (demand-side intake): firms receive applications, RFPs, and expressions of interest through a branded public portal; each submission is scored against the firm's profile and triaged with a Go/No-go decision.

Both directions converge on the same opportunities/workspaces abstraction and the same matching ensemble, knowledge graph, embeddings, and document-generation stack, so a firm's pipeline, records register, and AI tooling are unified regardless of how an opportunity entered the building.

How the platform fits together

The end-to-end flow, and where each module sits:

  1. Discovery and Matching is the front door of the outbound funnel. A global ingestion pipeline normalises 12+ tender sources into one canonical table (canonical_opportunities); a multi-signal matching ensemble turns "a firm" + "a tender" into a calibrated, explained fit score; the Notices feed is the raw universe and Featured is the per-firm, AI-ranked daily shortlist.

  2. Inbound (Projects) and the Public Portal are the demand-side on-ramp. Applicants submit through a branded portal (chat or form); submissions become scored projects/opportunities rows the firm triages and accepts or declines.

  3. Workspaces are the operational heart: a "Go" on either an outbound tender or an accepted inbound project spins up a 7-tab bid cockpit (requirements, data room, documents, AI-generated EOI, recordings, issuer outreach).

  4. The Knowledge substrate (the firm knowledge graph, documents, embeddings, capability claims, and curated knowledge items/packages) is the context layer every AI feature reads from. Without it, matching and generation run "cold."

  5. Issuers are the canonical buyer primitive (a lens over organizations) that workspaces, tenders, and the agent all point at.

  6. Records is the firm's spreadsheet-native ledger of every bid, two-way-synced with workspaces.

  7. Analytics measures the loop: firm KPIs/SLA/funnel on the operational substrate, and market intelligence over the full tender corpus.

  8. The Agent and Automations are the cross-cutting AI layer: a conversational, tool-using assistant and a declarative process engine that both operate on the same canonical data the rest of the platform uses.

  9. The Dashboard and Items cockpit is the daily entry point that triages it all, and Platform Capabilities (connectors, integrations, branding, RBAC, developer surfaces) is the control plane wiring Klarum into a firm's existing systems.

  10. Plans, Billing and Entitlements is what a firm pays for all of the above: a four-tier ladder with Free as the floor, a per-seat Business tier, enforced monthly meters on the Free tier's inference spend, and the trial that sits between them.

A note on the AI itself, true across every module below: LLM and embedding providers are environment-configurable through a LiteLLM factory. The dev/default path runs Qwen3-32B on AWS Bedrock (us.qwen.qwen3-32b-v1:0) for generation and BAAI/bge-m3 for embeddings; the production path runs Cohere Embed v4 on Bedrock's EU inference profile (eu.cohere.embed-v4:0) for embeddings and Claude/Anthropic (or Azure OpenAI / OpenAI / Gemini) models. Where a specific model is named below it is the currently configured choice, not a permanent vendor lock: the provider can be swapped by env var without code changes.

Account capabilities and surface scope

Klarum is a two-sided platform. The original product is the Supplier (consultancy/contractor) that hunts and bids on work; the Issuer/Buyer side (contracting authority that publishes tenders and assesses bids) landed later via the issuer-accounts work (#1975 issuer cockpit, #2082 org-capability model). One organization can hold both roles. Each module carries a scope saying which side it belongs to, so issuer-side features can be checked for bleed into supplier-only accounts.

Scope legend (the scope field on every module):

  • supplier - supply-side: hunt, bid, submit. The original product.
  • issuer - buy-side: publish notices, assess and award bids.
  • both - genuinely shared, or one surface with role-conditional behavior.

Two org-classification systems exist and they are not unified, so a reader should know which one a surface reads: organizations.meta.is_issuer (the legacy boolean that drives the nav label swap and the backend publish gate, and which cannot express "both"), and organization_capabilities (the buyer / supplier lex terms resolved by the shared org_capabilities tenancy helper, #2082), which is the intended capability substrate.

Modules

Every module Klarum ships, what it helps you do, and which plan includes it.

Showing 18 of 18 modules.

  • Discovery and Matching Engine

    Generally available
    Supplier
    From free

    Klarum's core AI engine. It ingests public tenders and aid-funded opportunities globally, indexes them in one canonical table, and scores every firm/tender pair with a calibrated, explained multi-signal ensemble.

    Capabilities

    • Notices (global tender index) An unscored, searchable index of every open tender Klarum ingests, served over SSE so rows paint progressively, with the org's own inbound portal submissions prepended to page 1.
    • Featured (per-org AI shortlist) The pre-scored daily shortlist read from featured_match_results, refreshed by a 06:00 UTC cluster-singleton cron with an 08:00 UTC digest email to opted-in users.
    • Send to Featured (on-demand scoring) Queues a single notice for the full orchestrator with real-time G3 extraction, returning 202 while the UI polls a pending skeleton every five seconds.
    • First-value warm-up Scores the whole candidate pool once for a brand-new org as soon as onboarding confirms its profile, so its feed is populated before it first reaches the dashboard (#1933).
    • Read-time filter presets Named presets re-slice the cached universe at the SQL layer, so switching one costs zero AI spend and returns instantly.
    • Derived primary CPV division Scores each notice's text against the 45 CPV division vectors and records the nearest division, used only where the source supplied no classification and only above a confidence floor.
    • Learning loop Every ensemble run logs to match_signal_log and user actions supply labels, so calibration and future learned weights improve from real bid behaviour.
  • Inbound (Projects) and the applicant view

    Generally available
    Supplier
    From free

    The org-facing inbox for applications it receives. Each submission lands as a scored Project with evidence highlights, and a Go promotes it into the same workspace machinery outbound tenders use.

    Capabilities

    • Triage queue A card grid of received applications with a NEW badge under 24 hours, extracted summary fields and per-criterion evidence bars.
    • Accept and Decline Accept promotes to a full workspace, seeds a checklist, writes a Go decision row and emails the applicant; Decline records the No-go.
    • Committee-pack export Bulk export of the inbound queue to Excel or a ZIP archive, for the committee pack a bid decision is taken from.
    • Applicant submissions view The applicant-facing mirror of Validated, Denied and In Progress submissions, with each one's best match score and status.
  • Public Portal and Intake Funnel

    Generally available
    Supplier
    From free

    A per-org branded public front door for inbound opportunities. An applicant submits by chat or dynamic form without an account and gets a reference number plus a self-serve status page.

    Capabilities

    • Conversational intake assistant A stateless slot-filling LLM conversation that collects the submission fields, never re-asks a known field, never invents a value and emits strict JSON at temperature 0.4.
    • One schema, two consumers A single builder schema drives both the portal render and the server-side validation, so the form a user sees and the rules the server enforces cannot drift.
    • Reference and status check A URL-safe INB-XXXXXXXX reference plus the applicant email acts as a bearer pair for the public status page; a mismatch 404s rather than confirming the reference exists.
    • Rate limiting on an unauthenticated surface 60 reads, 10 applies and 30 chat turns per minute, with a stateless chat so a bounced visit costs nothing.
  • Workspaces (Outbound Bid Cockpit)

    Generally available
    Supplier and issuer
    From basic

    One persistent cockpit that carries a single opportunity from "we should bid" to a submitted EOI: requirements, a searchable data room, AI document generation, meeting capture and issuer outreach.

    Capabilities

    • Overview tab At-a-glance command panel: urgency banner, tender facts, activity feed, editable notes, team, issuer context, embedded checklist mirror, timeline canvas and automations panel.
    • Items (Checklist) tab The workspace-scoped twin of the global Items inbox. Nothing writes directly: every origin stages an item_proposal, deduped by normalised title, promoted on accept.
    • Requirements tab (conditional) A split view of the tender's extracted requires_* claims against the verbatim evidence spans in the source text. One reusable panel: the issuer authors, the supplier reads read-only.
    • Notebook tab The workspace's quantitative surface: an ordered chain of model, assistant, transform and document cells that pipe into each other, every run recorded and every figure citable.
    • Data room tab Per-bid document repository plus collaboration substrate with Files, References, Decisions and Q&A sub-tabs, over semantic search of org knowledge.
    • Documents tab Disk-first attachments manager plus the freeform workspace brief the agent system prompt reads verbatim, capped at 8000 characters.
    • Generated EOI tab One-click generation of a world_bank_v1-templated EOI from org references and tender context, with per-section RAG, docxtpl assembly and PDF conversion.
    • Recordings tab Meeting capture, transcription and AI summarisation, with a three-pane viewer and a one-click conversion of action items into workspace items.
    • Conversation tab AI-assisted issuer outreach in two columns: a deterministic gap analysis of filled versus required EOI fields, and a tone-selectable AI-drafted email.
    • Completeness and lifecycle Every workspace carries a lifecycle stage, urgency, deadline, bid manager, team and a completeness score, which is what the list groups and the analytics funnel measures.
  • Issuers (Contracting Authorities)

    Generally available
    Supplier
    From free

    A supplier's CRM register of the buyer counterparties it cares about. An issuer is a lens over organizations where is_tenant is false, and it is the canonical buyer identity the rest of the platform points at.

    Capabilities

    • Overview tab Identity card, aggregate stats and the engagement rail. Pure CRUD and aggregation, powered by the same single backend read the workspace header uses.
    • Timeline tab A month-grouped issuer_notes feed with source badges (Manual, Agent, Email, Import). This is the module's AI seat: it receives add_issuer_note agent writes.
    • People tab Loginless contact rows held in members scoped to the issuer organization, managed by hand.
    • Linked workspaces tab An org-scoped relational join listing every workspace run against this buyer. The bridge to the Workspaces module.
    • Agent-written issuer note The first write tool the chat agent was given, behind a per-org feature gate, written with source=agent and attributed to the human chat user. The agent cannot choose the issuer.
  • Records (Proposals and EOI Ledger)

    Generally available
    Supplier
    From free

    The org's spreadsheet-native ledger of every bid, rendered as an inline editable Excel-style table with typed core columns, an open JSONB tail and a two-way sync with workspaces.

    Capabilities

    • Column dictionary Typed core columns plus an open org_fields JSONB tail, with firm-defined columns type-enforced against a closed type set. Admin-managed.
    • Two-way record and workspace sync A declarative map of about thirty field pairs mirrors edits both ways with deterministic converters, returning HTTP 409 with candidate options rather than guessing an ambiguous value.
    • Excel and CSV import One-step import of an existing bid-tracking workbook, with an LLM column mapper that returns a per-header confidence flag and a circuit breaker back to a deterministic miss.
    • Promote to Workspaces Turns a ledger row into a full working workspace in one click, creating and linking the two so the sync engine keeps them aligned from then on.
    • Branded PDF report Quarterly, by-sector or by-country reporting over the ledger, rendered as a branded PDF that lands back in the document library.
  • Documents

    Generally available
    Supplier and issuer
    From basic

    Klarum's central document library and reader, where every file the platform touches becomes parsed, chunked, embedded, citable evidence rather than an opaque blob in a bucket.

    Capabilities

    • One ingest path Every source, upload or cloud import or generated artifact, takes the same route to S3 plus a metadata row plus an async parse, chunk and embed pass with an explicit parse status.
    • Tender-match heatmap Embeds the tender text and scores every chunk of a document against it, rendering a per-section heat score so the passages that drove a match score are visible.
    • Citations and annotations RAG citations carry title, format, page and score, and document annotations record AI audits, user notes and risk warnings against a relevance score.
    • Usage loop Each document reports times used, last used, which EOIs and sections cite it and its average relevance, so a reference list earns or loses its place.
  • Knowledge (Org Knowledge Graph and Packages)

    Generally available
    Supplier and issuer
    From free

    The org-specific context substrate. It turns a pile of PDFs into a structured capability graph with evidence, plus a searchable knowledge corpus and shareable packages the rest of the AI stack reads from.

    Capabilities

    • Firm knowledge graph An org to category to capability to evidencing document tree, where every has_capability edge points back at the exact passage, page and confidence that justifies it.
    • Knowledge items Curated org-scoped records with a title, markdown body and a kind. A sweep embeds them every 30 minutes, so a new item is keyword-findable at once and vector-findable at the next sweep.
    • Knowledge packages Named, versioned bundles of items, exportable as ZIP or branded PDF and installable into a workspace or another tenant. Cross-tenant public packages form a marketplace.
    • Team composition Bulk-uploaded CVs are extracted for job title and seniority and rolled up into a view of who the org can actually deploy.
    • Ingest health Per-document parse and tag status with retry, bulk retry and reingest, and status synthesised defensively so the UI never shows a perpetual spinner.
  • Templates and Checklist Templates

    Generally available
    Supplier
    From basic

    Two org-owned template systems: a document section tree with typed variable slots that drives generation, and role-based checklist templates that seed every new workspace with a starting task list.

    Capabilities

    • Section tree and variable slots A hierarchical section skeleton with per-section generation prompts and typed variable slots declaring where each piece of org context inserts at generation time.
    • Fork with provenance An org forks a platform-shipped Standard template into a Custom one and the fork records meta.forked_from, so a customisation can always be traced back to its origin.
    • Checklist seeding and Apply template A default checklist is provisioned idempotently per org and copied once into each new workspace; the Apply picker is one relevance-ranked SQL query over issuer-matched, default and manual buckets.
    • Staffing-scope checklists Checklist templates can declare a staffing scope for criteria matching. The scope is scaffolded and stored; the matcher behind it is not yet wired.
  • Analytics (Org KPIs and Market Intelligence)

    Generally available
    Supplier
    From free

    Two reporting surfaces over the two core substrates: org KPIs, SLA and funnel on the operational tables, and market intelligence with a streaming natural-language analyst over the whole tender corpus.

    Capabilities

    • Org KPIs Workspace totals and stage split, EOIs sent all-time and rolling twelve months, average time to submit and a per-bid-manager breakdown.
    • SLA and deadline adherence Workspaces joined to canonical tender deadlines and bucketed on-time, late, missed, at-risk and on-track, each bucket clicking through to the workspaces behind it.
    • Pipeline funnel A Salesforce-shaped funnel combining snapshot conversion ratios with historical transition counts and average dwell time mined from the audit log by a window function.
    • Volume forecast A closed-form OLS regression over the last twelve monthly counts projecting three months ahead with a confidence band that widens with the horizon. Deterministic, computed inline in SQL.
    • Market Analysis Bot A retrieval-grounded streaming natural-language analyst: live market aggregates are injected as context so answers stay numerically faithful to the corpus.
    • Historical win rate A first-party aggregate over concluded bids broken down by country and donor or MDB. Descriptive today, and the substrate a predictive model would train on.
  • Corpus Coverage (public, audited)

    Generally available
    Supplier and issuer
    From free

    The one surface Klarum publishes outward about its own data: a per-market, per-source table of what the tender corpus contains, rendered from a hash-chained append-only snapshot anyone can re-derive.

    Capabilities

    • Metric registry Each metric's exact SQL and its plain-language meaning, denominator and exclusions live in one object, so a number cannot be computed one way for the page and described another way in a deck.
    • Append-only hash chain Snapshots are chained with the same integrity primitive as the workspace audit chain, append-only at the database with a unique prev_hash and a single-genesis index so the chain cannot fork.
    • Four publication gates Nothing publishes unless dbt data tests are green, the deployed transform fingerprint matches the checkout, the build is identifiable and the ingestion run was green.
  • Automations (Process Engine Console)

    Generally available
    Supplier and issuer
    From business

    The console over Klarum's process engine: declarative multi-step processes with a narrow auditable DSL, pluggable compute backends, per-step budget envelopes and a live runs ledger.

    Capabilities

    • Catalog of Standard and Custom processes Platform-shipped Standard definitions cover the bid lifecycle end to end; an org forks or authors Custom ones alongside them.
    • Runs ledger Every firing is recorded step by step with its inputs, outputs, cost and verdict, which is what makes an automated decision auditable after the fact.
    • Budget envelope Per-step and aggregate ceilings on tokens, latency and cost, enforced by the engine, so a runaway automation stops rather than billing.
    • Prompt a new automation A plain-English description becomes a validated ProcessSpec, capped at four steps and restricted to LLM-only steps so a bad draft can at worst waste tokens.
    • Citation stripping The EOI section path post-validates every [ref:id] citation against the supplied reference list and strips hallucinated ids, recording the event.
    • Contextual suggestions A first-match-wins regex rule table maps a checklist item to a suggested automation and a reason, deliberately not an LLM call so suggestion stays instant and free.
  • Agent (AI Assistant, "Klara")

    Generally available
    Supplier and issuer
    From basic

    Klarum's conversational assistant: a tool-using ReAct agent on LangGraph that reasons over the org's own data, calls tools to read and act on it, searches the web, and drives the UI of the page the user is on.

    Capabilities

    • Chat mode Streaming multi-turn conversation with tool use, citations and live thinking and tool-call blocks, persisted to process_runs so a session is resumable.
    • Notebook mode A Jupyter-style cell stack of promptable automations wired to the process engine and the knowledge API, for work that repeats.
    • Page-action bridge A server-stateless tool: the agent emits an action, the backend echoes it, and the frontend invokes the matching handler from its per-page registry. This is what lets the assistant operate the UI.
    • Contract manifest and state-edges A source-walked manifest maps every route to its components, testids, actions and dual doors, so an in-page view with no route of its own is still reachable and nothing is hand-maintained.
    • Cross-context isolation Row-level firm scoping on every SQL and RAG call plus a non-negotiable prompt rule that the agent may only answer about the pinned workspace, so one deal cannot leak into another.
    • Gated write tools Write tools sit behind a per-org opt-in flag and refuse when mis-wired, and confirm-gated proposals put a human between an intention and an effect.
    • Brand-aware document generation On request the agent produces a finished on-brand PDF dressed in the org's own design tokens, routing between approved brands by matching the new document to the org's past accepted ones.
  • Dashboard and Items Cockpit

    Generally available
    Supplier and issuer
    From free

    The command centre at the top of the authenticated app: a dashboard that triages what needs attention today, a cross-workspace items tracker, and a proposals queue every new item has to pass through.

    Capabilities

    • Action Center Overdue, due-today and due-within-seven-days workspaces bucketed by calendar day in UTC, each with a Run with Agent hand-off.
    • Self-hiding widgets Each dashboard widget disappears when it has no signal, so the page stays calm when the org is calm rather than showing a wall of empty states.
    • Latent capabilities A deterministic SQL traversal of the org's capability edges minus what it already declares, banded by rank, with a one-click Declare that lifts future match scores.
    • Proposals-first architecture Nothing writes directly to items. All four creation origins stage a proposal first, through one idempotent dedupe gate and one review surface, and items exist only on promotion.
    • The item model Typed content slots, directed inter-item links, sub-items, labels and a per-item activity log, with an assessed flag that is a human-judgement marker distinct from completion.
    • Process state buckets Per-org process states map onto canonical buckets so filtering by "open" works across every org's custom state names.
  • Issuer Procurement (Buy-Side, workspace-native)

    Generally available
    Issuer
    From free

    The buy-side of a procurement, re-homed onto existing primitives: an issuer publishes an OCDS notice, suppliers bid, and a multi-role assessment chain runs to a framework-weighted award.

    Capabilities

    • OCDS publish An OCDS release maps onto an opportunities row and idempotently creates a companion workspace linked both ways, so publishing produces a working data room rather than a listing.
    • Requirements authoring and extraction Requirements are claims of the same requires_* shape the supplier side reads, authored by hand or extracted from an uploaded spec by a structured LLM call with a regex fallback.
    • Evaluation framework A weighted MCDA definition held as a process_defs spec with criteria keyed to assessment roles, weights and gates, parametrizing the ranking rather than averaging it flat.
    • Multi-role assessment chain Dated, assignee-scoped role assessments, each mirrored as a tracked item so an evaluation obligation appears where that person already works.
    • Pre-qualified supplier panel Approved, conditional and rejected supplier tiers, shaped for later automatic classification but maintained by hand today.
    • Award hand-off Award flips the winning bid to WON, pushes a WON workspace and award letter to the supplier, and writes the contract into the supplier's own Records register.
  • The control plane that wires Klarum into an org's existing systems, governs who can do what, and exposes a developer surface. Supporting capability, not a headline tool.

    Capabilities

    • Connectors Authenticated pipes into procurement portals Klarum cannot read anonymously, with per-connector credentials encrypted at rest and a probe endpoint that validates them.
    • Integrations A server-side provider catalogue spanning storage, editor, comms, project management, CRM, signing and automation, with OAuth callbacks and a post-OAuth provisioning gate.
    • AI behaviour preferences Org-level generation preferences (tone, default output language, preferred and avoided terminology) that steer LLM drafting without touching matching scoring. Admin-only.
    • Branding and portal Per-org document branding assets - header logo (required for EOI generation), footer logo falling back to the header, and a cover hero image.
    • Organization and roles (RBAC) Three built-in role tiers plus tokenised invite-by-email restricted to the org's admin domains, with an active-org header so a user can belong to several orgs.
    • Custom roles and section scoping Business-tier admins define named roles and check which dashboard sections each may reach, derived from the org's plan so a role can never be granted an area the plan excludes.
    • Webhooks Subscribe an external URL to org activity events. Delivery runs on the durable outbox with HMAC-signed attempts, exponential backoff and at-least-once semantics keyed on a stable delivery header.
    • Scheduler Read-only admin observability over Klarum's cron jobs: last run plus full invocation history with status, latency, payload and replica id. Jobs run with cluster-singleton leader election.
    • Filter presets Personal colour-coded bundles of feed filters. "Standard" is the org-profile baseline; each named preset overrides it per key, and the default one's score threshold drives the daily digest.
    • Product catalogue Klarum's own answer to "what does this product ship", published anonymously and in-app from one validated artifact, with the wiring graph behind the auth gate.
    • Saved searches Named outbound filter sets, saved per member and reusable across the opportunity feeds.
  • Plans, Billing and Entitlements

    Generally available
    Supplier and issuer
    From free

    How an org pays for Klarum and what each tier is entitled to: a four-tier ladder with Free as the floor, a per-seat Business tier, enforced monthly meters on Free inference spend, and the trial between them.

    Capabilities

    • The tier ladder Four tiers low to high, Free, Basic, Business and Enterprise, with every Stripe lookup key round-tripping through one table so the webhook sync and the price resolver cannot disagree.
    • Capabilities per tier A capability is binary per tier: engine and exports and connectors from Free, doc generation from Basic, team seats and org settings from Business, and the enterprise block from Enterprise.
    • Meters A monthly ceiling on something a tier already holds, enforced by one atomic statement that row-locks the org, resets lazily on a UTC month roll-over and writes nothing once the cap is reached.
    • The Business trial A once-per-org trial of Business with a seven-day window to activate and three full days once activated, requiring no payment method and preserving data when it ends.
    • Seat billing (Business) Per-seat and metered with Stripe authoritative. A seat bills on acceptance, not on invite, with an idempotency key on the invitation id so a retried accept cannot double-bill.
    • Self-serve plan management Interval and plan changes are not self-serve. The Stripe Customer Portal session endpoint exists but no frontend component calls it, so the interval is chosen at Checkout.
  • AI/ML stack at a glance

    Generally available
    Supplier and issuer
    From free

    Consolidated reference of every model and service the platform uses, what each is for and where. Providers marked currently configured are env-pluggable through the LiteLLM factory.

Provenance

Catalogue version
2026.08.21
Schema version
2

The catalogue is served as JSON, without a login and with a version stamp on every response. Read it directly if you would rather check the source than the page.