Go back to Market Research
Sigma Computing supplies cloud software for analyzing warehouse data, building business applications, and automating workflows. Its spreadsheet interface generates database queries; input tables, actions, Python elements, and agents extend workbooks into applications. For supply chain teams, Sigma offers demand-planning templates, supplier and landed-cost analysis, and configurable planning workflows. 1 3 8
Overall supply chain score: 4.8/10
| Dimension | Score |
|---|---|
| Supply chain depth | 3.2/10 |
| Decision and optimization substance | 3.6/10 |
| Product and architecture integrity | 6.0/10 |
| Technical transparency | 6.6/10 |
| Vendor seriousness | 4.4/10 |
Sigma’s technical substance lies in making data applications easier to build, operate, and inspect. Its compiler, execution architecture, programmatic workbook representation, and documented evaluation tools are meaningful engineering. They do not supply the economic decision logic that determines what to buy, produce, or allocate under uncertainty. 2 10 12
The supply chain proposition exposes this distinction. The current planning template organizes forecast overrides and exception review; the broader agent narrative promises to remove manual handoffs. Meanwhile, the AI usage notice advises reviewing outputs before relying on them and disclaims responsibility for their inaccuracies. The gap concerns who computes, verifies, and maintains the decision, with what remaining labor and financial liability. 4 17 26
Sigma Computing versus Lokad
Consider replenishing a seasonal product whose supplier may deliver late. Sigma can bring the relevant records into a workbook, let users modify assumptions, run customer-provided calculations, and send results through configured actions. Its supply chain page emphasizes shared forecasts, scenario inputs, and analysis of costs. 3 The customer or implementation team must define the ordering policy and its treatment of uncertainty.
Lokad’s inventory optimization centers on computing operational decisions from probabilistic forecasts and economic consequences. Its Supply Chain Scientists maintain the numerical logic used to produce those decisions. The comparison is between a general application-building environment and a supply chain service organized around maintaining an economic decision process.
For the seasonal product, the important calculation concerns possible demand, receipt dates, leftover stock, and the value of alternative uses of money. A faster query or a more convenient override does not resolve that calculation. Conversely, a sound ordering method still needs reliable data, testing, and maintenance. Sigma documents useful infrastructure for those tasks; a customer-developed supply chain application must be evaluated on its own implementation and outcomes.
The perspective behind Lokad makes the cost of the decision process part of its economics. That cost includes the people maintaining formulas, integrations, permissions, and exceptions, even when their interface looks like a spreadsheet.
The actual supply chain mechanism
The current supply chain page illustrates reorder points as weekly demand multiplied by lead time plus safety stock, with target inventory cover and manager-approved transfers. It separately displays supplier lead-time variability. 3 The missing connection is how that variability changes the economic choice of order or transfer. A risk indicator beside a deterministic rule does not make the rule risk-adjusted.
The demand-planning template preserves a review queue
Sigma’s current tutorial describes a product-by-month plan built from moving averages and planner overrides. Users resolve each flagged exception before approval, with options to restore the baseline, enter another value, or accept the variance. AI summarizes the cycle, explains exceptions, and recommends approval. The baseline falls back through prior years and ultimately to zero when history is unavailable. 4
This is an administrative planning process with a simple numerical starting point. Its organizing question is whether people have resolved the exceptions. The economically important question is whether a different purchase or production decision would yield a better result.
A deviation from a moving average can be commercially sensible. Returning a plan to that average can be harmful. Neither operation establishes the value of inventory, the effect of substitution, the cost of a missed delivery, or the best use of shared capacity. A narrative explaining the deviation does not add those quantities to the decision.
The workflow also has a scaling problem. If assortment or planning frequency grows, a product-and-period exception queue can grow with it. Faster explanations can reduce time per review while retaining the underlying requirement to review. No measured remaining workload is supplied for this template.
A precise inconsistency in the forecasting instructions
The same tutorial describes MovingAvg([Units], 2, 2) as a two-period moving average with a two-period lag that avoids incomplete current data. 4 Sigma’s function reference says this expression averages the current row, two rows above it, and two below it. 5
The published formula therefore does not implement the stated lag. On a chronologically ordered history, a centered window can include observations that would not have existed at the forecast origin. Evaluating such a smoothed history as if it were a previously issued forecast would introduce look-ahead information.
The inconsistency is in the public reference design; the private workbook was not executed for this review. It is nevertheless a concrete warning about the forecasting care behind a product presented for operational planning. A valid evaluation must freeze the available information at each decision date and retain the appropriate product, location, and horizon.
The older ML forecasting feature has narrowed availability
Sigma introduced a Snowflake forecasting integration in October 2024. The current documentation says it is no longer available to new organizations. For existing users, it calls Snowflake’s forecasting function, requires manual retraining when source data changes, and does not support version tagging of forecast outputs. 6 7
This is a material lifecycle change. A historical feature announcement cannot be treated as an unrestricted current capability. It also illustrates the maintenance work hidden behind the promise of live data: current records do not automatically imply a current trained model.
Python and external models provide other implementation routes. 13 Their availability does not establish a delivered method for jointly representing demand, lead times, supplier failures, and dependent costs. Sigma’s public supply chain examples do not show those uncertainties entering a common monetary decision calculation.
The November 2026 agent article promotes demand sensing and rapid updates as high-value uses. 26 Faster refresh is an execution property. Its economic value depends on whether the new signal improves the decision at the horizon where a commitment can still change. Renaming frequent forecast adjustment does not establish that result.
Architecture and software bill of materials
The 2022 Sigma Workbook paper explains an actual computational design. Workbook operations become a query graph, which is resolved and compiled into SQL for the customer’s warehouse. The service mediates access and execution. Query results return to the browser, where a C++ engine compiled to WebAssembly can evaluate additional operations locally. Warehouse result reuse and materialized tables reduce repeated work. 2
Current architecture documentation continues this design and exposes generated SQL and timing information. 1 The SQL compiler is Sigma’s engineering contribution. The connected database provides much of the storage and query execution; its performance should not be confused with a Sigma forecasting or optimization algorithm.
| Layer | Documented components and responsibility |
|---|---|
| Query compiler | Current employer vacancy specifies Rust backend work and TypeScript frontend foundations. |
| Backend services | Another engineering role names Rust, Go, GraphQL, Node, and Kubernetes in its work description. |
| Browser computation | The 2022 paper describes C++ compiled to WebAssembly. |
| Customer data platform | Queries execute against the selected warehouse or database connection. |
| Python execution | Snowflake stored procedures or Databricks compute, depending on the connection. |
| AI models | Configured warehouse-hosted or external model providers. |
The recruitment descriptions, paper, execution setup guides, and AI notice identify these separate layers. 24 25 2 14 15 17
This architecture has a coherent center, but its costs extend beyond the Sigma subscription. A working application may consume warehouse queries, materialization refreshes, Python compute, model calls, and integration services. It also requires people to keep those components consistent.
Sigma’s Snowflake Python guide recommends a separate warehouse to keep Python workloads from slowing SQL queries and explains the memory-versus-credit trade-off. 14 Its Databricks setup uses all-purpose compute and recommends an automatic termination policy of at least three hours. 15 These are concrete operating choices with financial consequences. A notebook-like interface does not make computation free or remove resource planning.
Data ownership does not eliminate application dependence
Input-table data and edit logs reside in designated customer schemas. Sigma warns against modifying its underlying tables directly and directs users to create warehouse views for querying the data. Deleting an input-table element does not delete its stored data. 16
The customer retains the data platform, but the application still depends on Sigma’s structures, formulas, and execution semantics. Extracting results is easier than replacing the maintained application. Cleanup, retention, and migration therefore need an explicit plan.
Current workbook-as-code APIs provide a useful counterweight. The beta feature supports JSON or YAML representations, retrieval and updates, and validation without creating a workbook. The representation excludes source records and some configuration, including sharing and tagged versions. 12 It improves review and automation while leaving a Sigma-specific application to maintain.
Agents: execution is real, economic competence remains an application responsibility
Sigma agents can query configured data, use tools, and run on schedules. They are not restricted to conversation. 8 The current MCP interface also supports finding content, querying data, building workbooks, and calling configured agents. 11
These interfaces can remove copying and re-keying. They do not establish the adequacy of a replenishment rule or the value of the actions it selects. An MCP connector is an inexpensive access layer relative to building and validating a supply chain decision method. Building and validating that decision method remains the costly part of the supply chain application.
Sigma’s more substantial contribution is the ability to inspect and modify reusable application logic. Programmatic workbook management can help an agent improve formulas or workflows across a portfolio, rather than imitate a planner clicking through individual records. That possibility needs evidence of reliable changes, regression testing, and lower total maintenance effort.
Approval settings change meaning outside chat
The agent-building documentation says an action tool can require approval in a chat. It also says approval prompts are skipped when an agent runs automatically. The evaluation guide makes the same distinction for programmatic calls. 9 10
The current supply chain page presents a more restrictive workflow: scheduled agents draft changes, and a planner approves before anything changes. 3 Implementing that promise requires an explicit application control; it cannot rely on the chat approval setting alone.
A chat approval setting is therefore not a general authorization barrier. A purchasing application needs enforceable limits in the tools or downstream service: permitted suppliers, quantities, values, and state transitions. Otherwise moving a tested conversational workflow onto a schedule changes its safety properties.
This is not merely a documentation detail. The same agent can appear appropriately controlled during interactive review and operate under a different approval path in production. Tests must cover the actual invocation mode.
Evaluation tools are more useful than generic assurances
Sigma publishes a concrete evaluation workflow: versioned cases, expected outputs, API-driven runs, execution traces, and checks of whether tools were called correctly. It distinguishes human review, deterministic checks, and LLM-based judging, including the need to calibrate the judge. 10
Those mechanisms can support controlled improvements. They still require the customer to define what success means. An agent can call the right tool, return correct database values, and execute an economically poor purchase. Tests of the application must therefore include the adequacy of its assumptions and the resulting business consequences.
This is the holimization issue: an unexpected result may require revising the problem, not merely fixing a query. A reusable correction might change how shortages are valued, how substitutes are considered, or which actions are available. Sigma supplies development tools; the supply chain reasoning and operational validation remain to be built.
Python security: documented controls, consequential configuration choices
Sigma explicitly allows users to write Python, import libraries, and call APIs. Editing requires a dedicated permission, and execution uses the selected data-platform identity. OAuth uses the individual user’s credentials; other connection modes can use a configured role or service account. 13
The Snowflake path documents caller-rights stored procedures, administrator setup, and optional external access through configured network rules. 14 This is a specific control design, stronger than a certification badge or a vague promise of governance. It also makes deployment choices consequential: the code receives the authority of its execution identity.
The Databricks path delegates execution to a configured cluster and describes library installation, network egress, and permissions to attach to or restart compute. 15 Safe operation depends on the customer-controlled cluster, identity, dependency, and network configuration. These are production engineering responsibilities, even when the code author is an analyst.
A compromised package or generated script can misuse whatever data access and external destinations it has been granted. Damage must be bounded by the execution environment. Sigma exposes meaningful setup controls; the documented deployment paths do not establish that every customer application inherits a narrowly isolated environment automatically.
The warehouse boundary is not the whole data boundary
The architecture page repeatedly emphasizes warehouse-local execution and data remaining in the warehouse. 1 The AI notice explicitly describes transmission of prompts, customer data, and user information to the selected model provider; external models use the customer’s configured credentials. 17
The practical boundary depends on the enabled feature. Query pushdown can avoid maintaining another analytical copy while query results, browser use, and external AI processing still move information. Security review must follow those actual paths.
Recovery also needs separate treatment. Workbook history supports restoring prior versions, but the documentation warns that restoring an individual historical change does not restore input-table contents to that moment. 27 Restoring application structure is not necessarily restoring business state, much less reversing an order already sent to another system.
Productivity, configuration maintenance, and accountability
Armstrong’s savings concern a specific operational workload
Armstrong Transport Group’s case reports $150,000 in external vendor costs avoided through commission-calculation automation, with days of monthly manual work eliminated. It also reports 40% growth in contract-carrier volume over eighteen months during a broader data modernization project. Predictive AI models are described as future work. 28
The commission example identifies a task and a cost that can actually disappear. Carrier-volume growth is a different measurement: it does not isolate the software’s contribution or establish improved margins. Combining both into a general autonomous-planning return would lose the useful specificity of the case.
Payload reports substantial savings in report production
Payload’s named case reports that a standardized customer report fell from approximately $9,500 to $1,400 to build, test, and deploy, alongside a 50% reduction in dedicated BI manpower. It also describes delivery falling from four-to-six days to four-to-six hours. 18
Those are relevant labor measurements for an analytics product. The reduction from $9,500 to $1,400 is approximately 85%, however; the case’s description of more than 600% cost savings confuses a ratio with a reduction. The underlying claim can be useful without accepting the inflated percentage.
The case concerns report development and embedded analytics. It does not measure autonomous inventory decisions or the incremental effect of Sigma’s 2026 agents. A current business case should include licenses, warehouse consumption, maintenance, and the new workload created as more applications are built.
Blue Bottle separates the forecasting engine from the interface
In a January 2020 interview, Blue Bottle described a separate machine-learning consultancy building its pastry-demand model. Sigma measured differences between orders and model predictions, and staff coached cafes. The reported 8% improvement in order accuracy lacked a metric definition and an economic reconciliation. 19
The division of work is informative. Useful analytics and human follow-through can improve operations without the analytics vendor supplying the predictive engine. The same distinction applies when a modern agent calls an external model.
Configuration maintenance is software maintenance
Warehouse-backed applications accumulate formulas, table relationships, prompts, credentials, schedules, permissions, and downstream actions. Each is part of the executable business process. An easy initial interface can spread development faster than the organization spreads the ability to test and maintain it.
Sigma’s own March 2026 churn-model account shows the necessary work. It describes prototyping through Sigma and Python notebooks, expert feedback, an 85% recall objective, and subsequent production integration through dbt, with model monitoring and lifecycle management. 20 This is a customer-retention application inside Sigma, not a supply chain benchmark. It demonstrates that the platform’s maintainable use involves engineering beyond authoring a dashboard.
The relevant productivity measure includes the people who diagnose failures, update logic, review model behavior, and maintain integrations. Eliminating an analyst ticket can be valuable. Replacing it with uncounted work by business users does not establish a net saving.
The AI liability allocation weakens the autonomy proposition
The AI notice advises manual verification before decisions or actions, including oversight of automated pipelines, and disclaims liability for inaccuracies in AI-generated output. 17 Meanwhile, the current supply chain narrative presents agents as removing manual handoffs and acting within predefined limits. 26
The resulting economic proposition is incomplete. If every consequential output requires human verification, that labor belongs in the business case. If the customer automates without such review, responsibility for an inadequate result remains heavily with the customer.
A credible deployment would specify the decisions being automated, acceptable losses, evaluation period, remaining human workload, and who repairs deficient logic. Permission checks and an audit trail answer different questions from whether the purchased decision process earns its cost.
Technology history and roadmap integrity
| Period | Evidence | Implication |
|---|---|---|
| 2020 | Blue Bottle uses an external forecasting consultancy and Sigma for analysis and coaching. | Operational relevance predates current AI agents; prediction was supplied separately. |
| 2022 | The Workbook paper publishes the interface-to-SQL design and browser execution mechanism. | Original engineering supports the analytical core. |
| 2023 | Sigma announces AI-generated input-table and natural-language features. | The LLM expansion follows the emergence of generative AI. |
| 2024 | Snowflake ML Forecasting launches in beta. | A warehouse capability is exposed through Sigma. |
| 2026 | Agents are announced in April and documented in June release notes as beta. | The execution surface expands beyond reporting. |
| Current review | ML Forecasting is unavailable to new organizations; workbook-as-code remains beta. | Availability and maturity must be checked feature by feature. |
The dated publications and current manuals support this sequence. 19 2 21 7 22 23 6 12
The underlying architecture shows continuity. The historical record does not support attributing the older customer results to today’s agents, and the newer demand-planning claims require more than that continuity. A forecasting feature can narrow in availability while the sales narrative broadens toward autonomous planning.
The strongest evidence of a serious roadmap is the maintained compiler, explicit APIs, and inspectable evaluation process. The weakest part is the jump from those general tools to a supplied supply chain capability whose economics and joint uncertainty treatment remain unspecified.
Supply chain score
Supply chain depth
| Criterion | Score |
|---|---|
| Economic framing | 4/10 |
| Decision end-state | 4/10 |
| Conceptual sharpness on supply chain | 3/10 |
| Freedom from obsolete doctrinal centerpieces | 2/10 |
| Robustness against KPI theater | 3/10 |
Average: 3.2/10
Economic framing — 4/10. Costs can enter customer-built applications, but a common economic objective for operational choices is not supplied in the documented planning workflow. 3
Decision end-state — 4/10. Actions can reach other systems. The logic selecting supply chain commitments remains a separate implementation responsibility. 8
Conceptual sharpness on supply chain — 3/10. Rapid access to records is useful; it does not resolve the distinction between a forecast adjustment and an economically justified order. 26
Freedom from obsolete doctrinal centerpieces — 2/10. The reference planning process retains sequential forecast intervention and review. Its AI layer does not remove that structure. 4
Robustness against KPI theater — 3/10. Some labor baselines are concrete, but the Payload percentage is miscalculated and improved forecast presentation is not evidence of economic improvement. 18
Decision and optimization substance
| Criterion | Score |
|---|---|
| Probabilistic modeling depth | 2/10 |
| Distinctive optimization or ML substance | 4/10 |
| Real-world constraint handling | 3/10 |
| Decision automation and labor productivity | 5/10 |
| Resilience under real operational complexity | 4/10 |
Average: 3.6/10
Probabilistic modeling depth — 2/10. External models can be integrated, but the disclosed supply chain offering does not establish joint uncertainty used to select commitments. 8 13
Distinctive optimization or ML substance — 4/10. The compiler is substantive original engineering. Its query transformations solve a different problem from economic supply chain optimization. 2
Real-world constraint handling — 3/10. Builders can encode application rules. Coupled operational feasibility and economic trade-offs require their own maintained model. 9
Decision automation and labor productivity — 5/10. Scheduled execution and named report-production savings support real productivity. Recurring supply chain labor and agent-specific gains remain unmeasured. 8 18
Resilience under real operational complexity — 4/10. Evaluation and versioning support reusable corrections. Published supply chain evidence does not demonstrate diagnosing and reformulating an economically inadequate decision model. 10 27
Product and architecture integrity
| Criterion | Score |
|---|---|
| Architectural coherence | 7/10 |
| System-boundary clarity | 7/10 |
| Security seriousness | 5/10 |
| Software parsimony and ownership cost | 4/10 |
| Compatibility with programmatic and agent-assisted operations | 7/10 |
Average: 6.0/10
Architectural coherence — 7/10. A defined compilation and execution architecture connects analysis, applications, and extensions. 1 2
System-boundary clarity — 7/10. Detailed setup guides identify where code and models run. Broad warehouse-local messaging obscures some feature-specific data movement. 14 17
Security seriousness — 5/10. Concrete identity and egress controls are documented. Approval behavior and customer-managed runtime configuration still create consequential boundaries to engineer. 14 9
Software parsimony and ownership cost — 4/10. Existing warehouse infrastructure can be reused, but compute, model calls, application maintenance, and integration costs remain material. 1 15
Compatibility with programmatic and agent-assisted operations — 7/10. Code representations and APIs support automation of application maintenance, with explicit feature limitations. 12
Technical transparency
| Criterion | Score |
|---|---|
| Public technical documentation | 8/10 |
| Inspectability without vendor mediation | 7/10 |
| Portability and lock-in visibility | 5/10 |
| Implementation-method transparency | 7/10 |
| Evidence density behind technical claims | 6/10 |
Average: 6.6/10
Public technical documentation — 8/10. Papers, function references, execution guides, and detailed examples expose mechanisms and limitations. 2 5 14
Inspectability without vendor mediation — 7/10. The public record permits checking specific claims and finding contradictions without a sales demonstration. The actual deployed application remains customer-specific. 4 5
Portability and lock-in visibility — 5/10. Data location and application representations are clear. Migration still requires reproducing Sigma semantics and configuration. 16 12
Implementation-method transparency — 7/10. Tutorials and evaluation instructions explain substantial construction and testing work. They do not quantify its lifetime staffing requirement. 10 20
Evidence density behind technical claims — 6/10. Analytical architecture has concrete support. Autonomous supply chain economics has much weaker demonstrated substance. 2 26
Vendor seriousness
| Criterion | Score |
|---|---|
| Technical seriousness of public communication | 4/10 |
| Technology roadmap integrity | 5/10 |
| Conceptual sharpness | 4/10 |
| Economic accountability | 3/10 |
| Defensibility in an agentic-software world | 6/10 |
Average: 4.4/10
Technical seriousness of public communication — 4/10. Inspectable engineering coexists with an incorrect forecasting explanation and overstated savings arithmetic. 4 5 18
Technology roadmap integrity — 5/10. The analytical core has continuity, while the withdrawal of a forecasting feature from new organizations narrows what earlier announcements establish. 2 6
Conceptual sharpness — 4/10. The application-platform role is clear. Supply chain messaging conflates quicker workflow execution with an adequate decision method. 26
Economic accountability — 3/10. Named labor measurements are useful. Broad AI output disclaimers and unquantified recurring review leave the buyer carrying much of the performance risk. 18 17
Defensibility in an agentic-software world — 6/10. Maintained compilation, application semantics, and deployment tooling have value beyond a chat interface. The supply chain specialization must still be supplied elsewhere. 24 12
Sources
[1] Warehouse-first architecture
Warehouse-first architecture. Current query execution and caching description. Accessed November 4, 2026.
[2] Sigma Workbook: A Spreadsheet for Cloud Data Warehouses
Sigma Workbook: A Spreadsheet for Cloud Data Warehouses. Vendor-authored PVLDB paper, 2022. Accessed November 4, 2026.
[3] Sigma for Supply Chain Teams
Sigma for Supply Chain Teams. Current supply chain use cases. Accessed November 4, 2026.
[4] Demand Planning App Template
Demand Planning App Template. Current reference application and its formulas, exception workflow, and AI summaries. Accessed November 4, 2026.
[5] MovingAvg function reference
MovingAvg function reference. Function semantics and centered-window example. Accessed November 4, 2026.
[6] Create time series forecasts with ML Forecasting
Create time series forecasts with ML Forecasting. Current availability restriction and retraining limitations. Accessed November 4, 2026.
[7] October 4, 2024 release notes
October 4, 2024 release notes. Dated launch of the Snowflake forecasting integration. Accessed November 4, 2026.
About Sigma agents. Agent scope and execution modes. Accessed November 4, 2026.
Build Sigma agents. Tool permissions, approval behavior, and configuration. Accessed November 4, 2026.
[10] Build an evaluation suite for your agents
Build an evaluation suite for your agents. Evaluation methods, programmatic execution, and testing limitations. Accessed November 4, 2026.
Use the Sigma MCP server. Current MCP capabilities and authentication. Accessed November 4, 2026.
[12] Manage workbooks as code (Beta)
Manage workbooks as code (Beta). Beta API representation and its limitations. Accessed November 4, 2026.
[13] Write and run Python code in Sigma
Write and run Python code in Sigma. Python features and execution identities. Accessed November 4, 2026.
[14] Set up a Snowflake connection for Python
Set up a Snowflake connection for Python. Snowflake stored-procedure, egress, and resource setup. Accessed November 4, 2026.
[15] Set up a Databricks connection for Python
Set up a Databricks connection for Python. Databricks cluster, library, and permission setup. Accessed November 4, 2026.
Input tables overview. Writeback storage, retrieval, and removal behavior. Accessed November 4, 2026.
[17] Notice for enabling AI-enabled features in Sigma
Notice for enabling AI-enabled features in Sigma. AI usage notice, last updated November 7, 2025. Accessed November 4, 2026.
[18] Payload unlocks a new revenue stream
Payload unlocks a new revenue stream. Named Payload case; report-production costs and labor. Accessed November 4, 2026.
[19] Blue Bottle: Lucy Dana interview
Blue Bottle: Lucy Dana interview. Lucy Dana interview, January 30, 2020. Accessed November 4, 2026.
[20] How We Built a Churn Prediction ML Engine in Sigma
How We Built a Churn Prediction ML Engine in Sigma. Irina Tilak’s internal implementation account, March 12, 2026. Accessed November 4, 2026.
[21] Databricks Data and AI Summit recap
Databricks Data and AI Summit recap. July 6, 2023 recap describing the announced AI features. Accessed November 4, 2026.
[22] From Insight to Action: Introducing Sigma Agents
From Insight to Action: Introducing Sigma Agents. April 8, 2026 agent announcement. Accessed November 4, 2026.
[23] June 12, 2026 release notes
June 12, 2026 release notes. June 12, 2026 release notes identifying agents as beta. Accessed November 4, 2026.
[24] Software Engineer — Compiler
Software Engineer — Compiler. Employer posting; public recruiting API records update August 12, 2026. Accessed November 4, 2026.
[25] Staff Software Engineer — Backend
Staff Software Engineer — Backend. Employer posting; public recruiting API records update August 12, 2026. Accessed November 4, 2026.
[26] AI agents for supply chain and demand planning
AI agents for supply chain and demand planning. Sean Gross article, November 2, 2026. Accessed November 4, 2026.
[27] Workbook versions and version history
Workbook versions and version history. Version history and input-table restoration behavior. Accessed November 4, 2026.
[28] Armstrong Transport Group contract freight management
Armstrong Transport Group contract freight management. Named customer account of commission automation and contract-carrier volume. Accessed November 4, 2026.