Executive summary

Freight forwarders are being told they need AI. Most of the AI tools they’re shown were trained on the open internet and bolted onto generic SaaS. Those tools can write a poem about a shipment. They cannot tell a forwarder why a particular invoice is wrong, why a carrier has degraded on a specific lane, or why an anomaly in this week’s invoice batch matters.

This paper introduces Synthetic Intelligence — a category we use to describe intelligence that is engineered, narrowly scoped, and grounded in real freight data structures rather than retrofitted from internet-scale chatbots. We explain why the distinction matters, what it looks like in practice across eight purpose-built modules, and how the architecture differs from the generic AI products freight forwarders are currently being pitched.

1 — The category problem

“AI-powered” has become the most common claim in B2B logistics software. The phrase is now functionally information-free: it appears on incumbent TMS marketing, on warehouse-management vendors, on customer-portal startups, and on freight-broker platforms. Buyers tune it out. RFP procurement teams filter it as table-stakes language.

Worse, “AI-powered” hides the variance. The capabilities being marketed range from:

A chatbot wrapper around an off-the-shelf LLM with no domain grounding
Predictive analytics over generic time-series data
A retrieval layer over the vendor’s own database
An automation engine driven by hand-authored rules
Genuine machine-learning models trained on freight-specific data

These are not the same thing. They have different operational characteristics, different failure modes, different audit trails, and different costs. A forwarder evaluating “AI-powered” features cannot tell the difference from the marketing.

We propose a different vocabulary.

2 — What “Synthetic Intelligence” means

We use Synthetic Intelligence the way the chemicals industry uses synthetic — not as a euphemism for fake, but as a description of something engineered for a purpose. Synthetic fibers are stronger than the natural ones they replaced. Synthetic motor oil outperforms petroleum. Synthetic biology produces compounds that would never have evolved.

Synthetic Intelligence in freight is the same idea applied to intelligence. The underlying technology — large language models, embeddings, retrieval augmentation, statistical models, rule engines — is the same toolkit every other vendor has. The difference is the design intent: each module is engineered around a specific operational problem in freight forwarding, with explicit scope, explainable outputs, and tenant-bounded context.

Three commitments differentiate Synthetic Intelligence from generic AI:

Engineered, not bolted on. Each module exists because a specific operational problem demanded it. The PO-to-invoice reconciliation module exists because forwarders bleed margin to charge variances; it is built around contracted rate cards and freight-specific charge codes, not generic invoice-matching templates.
Tenant-scoped context. Every Synthetic Intelligence query reads from the tenant’s own database only. There is no model trained on other tenants’ data, no cross-tenant retrieval. Per-tenant SQL Server isolation is the substrate; the AI layer inherits it by design.
Explainable outputs. Every alert can be inspected. Every prediction has a confidence interval. Every reconciliation discrepancy points to the source records that triggered it. Operators can override; compliance can audit; customers can verify.

3 — The eight modules

PulseCargo’s Synthetic Intelligence ships as eight purpose-built modules. Each maps to a specific operational pain point we observed repeatedly across CargoWise-running freight forwarders.

3.1 Pulse Chat

Conversational Q&A grounded in the tenant’s TMS data. A customer or operator asks “Where is PO-44218?” or “Why was I charged more than last month on my Shanghai-to-LA lane?” and gets a specific answer that cites the actual records. Available in 15 languages. Translates TMS milestone codes (“FCL_MILESTONE_05_CLEAR”, “DECON”) into human language as part of the answer.

The model is provider-pluggable: Azure OpenAI by default; OpenAI, Anthropic, Google Gemini, and self-hosted Ollama can be configured per tenant. Tenant administrators control their model choice; PulseCargo never trains on customer data for cross-tenant model improvement.

3.2 Pulse Watch

Cost variances, transit-time outliers, billing mismatches, and carrier-pattern breaks surfaced the moment they appear. Every charge against the tenant’s historical baseline; every transit time against the lane’s distribution; every carrier’s behavior against its own recent record.

Pulse Watch is not a model trained on freight broadly. It is a per-tenant statistical layer that learns the tenant’s normal and surfaces deviation from it. New customer with no history? The first month is the calibration period and the system says so explicitly rather than producing low-confidence noise.

3.3 PO ↔ Invoice Reconciliation

Compares purchase orders to ASNs to invoices and flags discrepancies before approval. The engine ships with header-level rate variance detection and missing-charge detection today. Line-level math, multi-currency, tax, and fuel surcharge handling are on the build roadmap and we are explicit about that scope on the first call rather than overpromising.

The reconciliation surface is paired with a tenant-configurable rule engine. Forwarders define their own contracted rates, audit rules, and tolerance thresholds; the engine catches deviation and queues exceptions for finance review.

3.4 Pulse Score

Per-lane, per-mode, per-season scorecards across the tenant’s carrier roster. On-time percentage, transit-time variance, charge-discrepancy rate, document-completeness rate. Computed from the tenant’s own shipment history, not from carrier self-reporting.

This module exists because forwarders consistently told us they renegotiate carrier contracts annually based on what amounts to tribal knowledge. Synthetic Intelligence replaces tribal knowledge with audit-able data.

3.5 Pulse Dox

Pulls structured fields from uploaded BOLs, commercial invoices, packing lists, and certificates of origin. Azure Document Intelligence under the hood, with per-tenant credentials so the customer’s documents are processed under the customer’s contract terms with Azure.

Once fields are extracted, downstream modules — particularly Reconciliation — can consume them as structured data instead of operators retyping invoice amounts into spreadsheets.

3.6 Pulse Trace

Natural-language shipment narrative across linked entities. Given any shipment reference, Trace assembles a single-sentence story of the journey across linked POs, ASNs, invoices, exceptions, and customs entries — the kind of summary an ops manager assembles by hand from five browser tabs.

Trace is graph analysis on the tenant’s own data, presented as readable English. Operators see the same answer they would have constructed manually, instantly.

3.7 Pulse IQ

Per-shipment timeline that aggregates outputs from every other intelligence module into one chronological view. Open any container, PO, or invoice and see the full insight stream: anomalies surfaced, charge audit findings, reconciliation diagnostics, ETA revisions, document extraction events.

Insights is composition, not new prediction. It removes the most common ops complaint about feature-rich platforms: “the data is in there, but I have to know which module to open.”

3.8 Pulse Flows

Visual workflow builder. Trigger → context retrieval → LLM step (with tool loop) → tool execution → audit. Tenants define their own automations across the platform: when a charge variance exceeds a threshold, run the audit detail prompt and queue the exception for finance review; when a container milestone hits a delay pattern, run Trace and notify the customer in their language.

Phase 1 — backend execution loop and manual trigger — shipped today. Phase 2 — the visual builder UI — is rolling out this year. We document the phase split here rather than discovering it during procurement.

4 — What we deliberately do not claim

Synthetic Intelligence is a smaller claim than most AI vendors make. It is not artificial general intelligence. It is not a self-improving black box. It is not autonomous decision-making. It is not a chatbot that replaces operations teams.

We make a point of writing down the boundary because the buyer is the one who pays the cost when a vendor overpromises:

No tenant-trained models today. PulseCargo’s tenant scoping is at the retrieval and context layer, not the training layer. Each tenant’s queries return results based on their own data, but the underlying language model is shared. We do not claim per-tenant model training because we have not built per-tenant model training. If a buyer’s procurement team needs that, the conversation needs to happen up front, not after the contract.
No autonomous execution loop in production. Pulse Auto-pilot configuration ships at Enterprise tier; the actual execution loop for end-to-end PO-to-invoice reconciliation without human approval is still in scaffold. Marketing does not claim the execution loop today. We will when it lands.
No “AI replaces your operations team” framing. Every Synthetic Intelligence module is positioned as an instrument for the operator. The model produces explainable output; the operator decides. Forwarders who tried to replace headcount with AI in 2024 are now hiring back.
No customer-attributed savings figures without signed reference release. We have observed-savings data in early deployments. We do not publish specific numbers until a reference customer has signed off on the quote and the figure. Until then the public marketing does not say “Customer X saved $Y/month.”

5 — Architectural foundations

Synthetic Intelligence sits on top of three substrate decisions that are unusual for SaaS vendors at our size, and that procurement teams typically notice:

5.1 Per-tenant SQL Server database isolation

Not row-level filtering. Not a shared schema with a tenant_id column. Each customer is provisioned a separate SQL Server database. The middleware resolves the tenant per request and routes to the correct database. Cross-tenant queries are architecturally impossible because the connection string is wrong.

This is more expensive operationally than row-level isolation. We pay for that decision because compliance auditors notice it within five minutes of a SOC 2 review. (See Per-Tenant Database Isolation Architecture for the full deep dive.)

5.2 Multi-provider AI abstraction

The Synthetic Intelligence layer is provider-pluggable. By default we use Azure OpenAI. Tenants can configure OpenAI, Anthropic, Google Gemini, or self-hosted Ollama instead. Two reasons matter:

A tenant whose own contractual obligations require self-hosted inference can self-host without leaving PulseCargo.
A tenant whose preferred model improves can switch models without leaving PulseCargo.

We do not lock customers into a model choice we made.

5.3 Audit logging by design

Every Synthetic Intelligence query is logged with timestamp, user, tenant, model provider, and the records retrieved. The audit log is queryable by tenant administrators. SOC 2 evidence collection is the reason; tenant trust is the by-product.

(Outbound integration audit logging — Stripe, TMS providers — is partially implemented and being expanded; we surface that gap in our security documentation rather than discovering it during a SOC 2 evidence review.)

6 — How to evaluate Synthetic Intelligence vendors

For freight forwarders being pitched “AI-powered” platforms, six questions cut through the marketing:

Show me the failure mode. When the AI is wrong, what does the operator see? “It rarely is” is the wrong answer.
Where is the tenant boundary? At the retrieval layer? At the context layer? At the training layer? Vendors often claim “tenant-scoped AI” without specifying which.
What model are you using, and can I change it? Lock-in to a single model provider is a procurement risk that surfaces 18 months in.
Show me the audit log. Per-query logging should exist. If it does not, the SOC 2 review will catch it later.
What is the scope today vs the roadmap? A vendor who says “everything is shipped” is either lying or has a small product. The honest answer is a list of what ships and a list of what is in flight.
Will you commit the scope in writing? Marketing claims should map to contractual capabilities. A vendor who will commit to “PO-to-invoice reconciliation including line-level math and multi-currency by Q3” is being honest about today’s scope and tomorrow’s plan; a vendor who will only commit to “AI-powered reconciliation” has not done the work.

7 — About PulseCargo

PulseCargo is the Synthetic Intelligence layer for freight forwarders. We connect to the existing TMS — CargoWise live today, with Magaya, Descartes, and GoFreight on the integration roadmap — and surface the operational layer the TMS was never designed to deliver: customer-facing portal, embedded Power BI, eight Synthetic Intelligence modules, software escrow, ISO 14083 carbon reporting, and a multi-framework compliance platform.

Per company. Not per seat. Five tiers from Starter Lite (self-service evaluation) to Enterprise+ (multi-region, dedicated infrastructure). Talk to sales for tier scoping and pricing.

To request a demo: pulsecargo.ai/contact.

This paper is © 2026 PulseCargo, Inc. The Synthetic Intelligence category framing and accompanying language are part of PulseCargo’s brand positioning and may be reproduced with attribution. PULSECARGO is filed with the USPTO under Section 1(b) Intent to Use; the ™ designation is in effect.

Synthetic Intelligence for Freight Forwarders