Go back to Market Research
Optilogic develops software for supply chain network design, transportation analysis, simulation, and inventory-policy optimization. Its Cosmic Frog environment lets modeling teams compare facilities, sourcing arrangements, flows, routes, and operating policies. DataStar prepares the data and workflows; Ada assists with building, running, and interpreting models. 1 14
Overall supply chain score: 5.7/10
| Dimension | Score |
|---|---|
| Supply chain depth | 5.4/10 |
| Decision and optimization substance | 5.8/10 |
| Product and architecture integrity | 5.6/10 |
| Technical transparency | 6.6/10 |
| Vendor seriousness | 5.0/10 |
Optilogic’s core is a modeling environment with several distinct numerical engines. Neo uses mixed-integer linear programming for network design. Throg simulates operational events, and Dendro searches for improved policies by running simulations. That last capability matters: uncertainty can participate in the selection of policies, rather than appearing only in a report after an optimization. The harder questions are whether the simulated future is credible, whether the objective represents actual economic value, and how much work is required to keep both valid. 2 3
The public documentation is unusually detailed about those engines. It also exposes significant limitations: aggregation in network optimization, subjective scoring in policy search, and practitioner-written Python without a comparably detailed account of enforced containment. Recent AI releases broaden access to modeling, but the strongest named customer case still describes a specialist team becoming a bottleneck. Optilogic is better substantiated as a supply chain design workbench than as an autonomous system delivering continuously optimized economic decisions. 4 12 23
Optilogic versus Lokad
Optilogic equips a customer or consulting team to build supply chain models and investigate alternatives. Its own specialists can help establish those models. Lokad combines a programmable platform with Supply Chain Scientists who develop and maintain the data preparation, uncertainty forecasts, economic logic, and production of recurring decisions. The distinction is partly the delivered service: analytical capability operated by a modeling team versus an ongoing process for producing decisions. 23 Lokad’s inventory optimization offering
The overlap is substantial when the question concerns inventory or sourcing. Optilogic can simulate detailed events and search across policy combinations. Lokad’s distinguishing perspective is to express the value of decisions in money and evaluate them against probabilistic futures, including supply uncertainty. Optilogic exposes configurable objectives, but the documented default examples often translate costs and service into weighted utility scores. 3 4
That difference determines what “better” means. A warehouse opening, a replenishment rule, and a production commitment should be judged by their consequences for the same business. A weighted combination of normalized KPIs can change the apparent winner without any change in those consequences. Lokad’s Introduction to Supply Chain develops the broader economic perspective behind its implementation.
Both approaches require maintenance. A programmable system does not eliminate the need to correct data interpretations or revise objectives. The relevant comparison includes Optilogic’s modelers and consultants, Lokad’s Supply Chain Scientists, and the cost of testing and deploying corrections. The advantage belongs to the approach that turns those corrections into better decisions with less recurring work.
The engines and their economic limits
Neo: the limits of network optimization
Neo is explicitly a mixed-integer linear program, using Gurobi. Optilogic exposes termination and numerical controls and permits export of the generated LP formulation. Its own Dendro introduction explains that network optimization commonly aggregates products, customers, and time periods, making detailed replenishment rules and daily capacity behavior difficult to evaluate. 2 3
This is a central modeling limitation. A fixed network calculation can select an inexpensive configuration for its specified demand, costs, and capacities while missing the consequences of uncertain arrivals, congestion, substitutions, or unavailable materials. Integer variables do not restore the uncertainty removed before the solver runs.
Expanding the formulation into many possible futures does not provide an inexpensive remedy. The combinations of future demand, supply, and operational choices multiply while the physical and commercial behavior remains nonlinear. Aggregation or separate subproblems can make the computation manageable by removing interactions that matter economically. Running many such models concurrently increases the alternatives examined; it does not establish that any of them represents the supply chain adequately.
The practical test is therefore not simply whether the solver reports a small optimality gap. It is whether observed operational failures lead to a revised problem that makes better decisions: different available actions, corrected data semantics, and a better account of costs and uncertainty. This is the distinction developed in holimization.
Throg and Dendro: real simulation, conditional conclusions
Throg models individual demand lines, shipments, inventory policies, and processing events. Demand, supply, and travel variability can be represented. Dendro then changes selected inputs and evaluates their simulated performance. Before using it, the modeler must establish and validate the underlying Throg model. 3
The demand documentation permits explicitly entered orders or generated order profiles, including disaggregation of monthly forecasts into assumed or inferred ordering patterns. Distribution inputs and user-defined histograms are supported. These mechanisms give the modeler more expressive power than an average-demand network calculation. They do not establish that the resulting distributions forecast the actual future, especially when delivery delays and demand peaks are dependent. 6 7
The genetic algorithm represents a complete collection of policies across the network, simulates each candidate, and retains and recombines successful candidates. It therefore considers interactions between facility-product settings. The implementation is more substantial than independent SKU-by-SKU random trials. Current run settings also offer Fast Dendro, which adjusts reorder points toward service targets, and a hybrid with the genetic search. 31 2
The search still depends on the policy family, permitted ranges, and adjustable variables selected by the modeler. Input-factor guidance recommends excluding low-impact combinations and grouping similar items to manage the search. That can reduce computational effort while excluding a decision or interaction needed for a better result. More simulation does not repair an omitted action. 5
Utility scores can move the objective
Dendro’s output-factor guide translates metrics into utility curves and combines them with weights. Its examples separately score total cost, on-time-in-full service, and holding cost. The curves can automatically expand when a new extreme is discovered, recalculating earlier scores. 4
This creates an economic problem. Changing the cost range used to normalize a metric changes the value of a utility point. With other criteria held fixed, the effective exchange rate between dollars and service can therefore move as the search discovers alternatives. That is not a change in the customer’s actual economics.
A coherent monetary objective can be implemented only if the modeler supplies the relevant costs and consequences consistently. The ability to configure arbitrary criteria is useful, but it does not perform that work. Holding cost, lost margin, service penalties, and obsolescence must not be double-counted or replaced by weights chosen because a chart looks balanced.
The separate DART risk rating is another score rather than a forecast of loss. It combines factors such as source count, geographic exposure, and concentration using configured weights and bands. A network can score well while retaining a costly common failure mode, or score poorly because of a concentration that is economically justified. The risk rating needs a link to disruption probabilities and monetary consequences before it can guide capital allocation. 8
Digital-twin validation and customer economics
A detailed simulation is a high-dimensional forecast: it predicts future flows, queues, service, and costs under decisions not yet taken. Reproducing the past checks accounting and model consistency. It does not show that the model predicts the consequences of a different network or policy.
The May 2026 store-network case, authored by partner Sequoia, makes this distinction concrete. It reports matching historical network cost within 0.2%, then models a program reducing annual cost from £42.0 million to £26.1 million. The levers include delivery frequency, windows, fleet mix, and depot changes. The study explicitly avoids adding isolated savings together and excludes a milk-removal option whose alternative cost is unknown. Those are useful modeling disciplines. 24
The remaining gap is predictive validation. The 0.2% historical fit does not establish that reduced delivery frequency preserves store availability, that the changed receiving workload remains acceptable, or that a redesigned network realizes the modeled savings. No deployment period or realized financial reconciliation accompanies the program. High apparent fidelity to an existing cost total is especially weak evidence for a new operating regime.
Castrol provides stronger implementation evidence. Its October 2026 case describes an internal center of excellence replacing repeated external studies with a refreshable global model. Optilogic consultants helped build the first model. The case reports millions of dollars unlocked within six months, much of the change already implemented, and subsequent work on European distribution, Australian bulk delivery, and tariffs. 23
The same case states that demand for the central team’s work now exceeds its capacity. Projects are backlogged, and Castrol plans regional superusers while retaining model-building skills centrally. Reuse has improved the process, but analytical labor remains a limiting resource. The unresolved productivity question is how much time the full team spends maintaining models and validating changes per implemented improvement.
The anonymous automotive case reports 11.6% cost savings after exploring production relocation and sourcing alternatives. It also describes approximately forty scenarios and extensive participation by subject-matter experts. Its wording moves between modeled potential and costs ultimately cut, without providing a deployment timetable or accounting reconciliation. It is weaker economic evidence than a named customer describing implemented changes. 25
Across these cases, the missing financial bridge is total ownership cost: software, computation, integration, internal specialists, consulting, and the work required to execute the recommendations. Network savings can justify substantial modeling expenditure. Their magnitude does not eliminate the need to measure that expenditure or explain which claimed benefits were realized.
Ada, MCP, and the productivity proposition
Ada can prepare and change model data, launch engines, diagnose runs, and produce reusable artifacts. The Executive agent is read-only, while modeling and cleansing agents have broader capabilities. The architecture describes tool use, iterative reasoning, logs, and specialist delegation. These are actual automation mechanisms beyond generating a textual answer. 9 10
The numerical result still depends on the model being built. An agent that produces a valid Anura database has not demonstrated that the selected constraints, uncertainty assumptions, or objective represent the business. Faster model construction can accelerate the production of a wrong model just as readily as a useful one. The productivity gain must be measured after correction and validation.
The MCP connector adds another conversational layer: an external assistant exchanges requests and responses with Ada and helps turn results into reports or other artifacts. That interface is inexpensive to reproduce and provides no evidence of a new supply chain algorithm. Its strategic weakness is preserving the analyst’s sequence of questions, scenarios, and presentations as the operating pattern. The stronger opportunity is for agents to maintain and improve reusable decision logic. 11
The connector does expose boundaries: it inherits the user’s platform permissions, and Optilogic recommends approval for write and delete tools, including recursive folder deletion. Prompts and returned data also pass through the external assistant. These controls limit some actions, but the quality and confidentiality of the combined workflow cannot be inferred from the existence of the connector. 11
Configuration and ongoing cost
DataStar exposes projects, macros, tasks, and Python/SQL transformations. Its integration guide documents direct PostgreSQL connections and leaves archiving previous input files to the user. A repeatable workflow reduces manual preparation, but its transformations and assumptions become software that someone must review, test, and maintain. 14 15
Optilogic’s utility documentation explicitly encourages editing and sharing Python scripts. That flexibility makes it possible to repair or extend a model, but also creates dependencies between customer code, database schemas, solver behavior, and platform releases. The ownership cost includes regression testing and diagnosis when a formerly valid workflow produces a different answer. 13
AI usage adds another operating cost. Ada consumes organization-level credits whose conversion is not one-to-one with model tokens; consumption depends on the request and its execution. No fixed per-task rate is published. Direct solver runs do not consume Ada credits, while asking Ada to run them does. Exhausting the shared pool disables Ada and DataStar agent tasks until more credits are obtained through support. 30
A credible productivity comparison would measure the complete process: source refresh, transformation maintenance, model revision, scenario execution, result checking, and implementation. Time saved on one step does not establish a proportional increase in delivered decisions.
Technology history and roadmap integrity
Optilogic’s history is a progression from cloud modeling and extensibility to language-assisted modeling and agent orchestration. The published changes are real; their advertised economic magnitude is less well established.
| Period | Announcement and mechanism | Follow-through |
|---|---|---|
| 2020–2023 | Gurobi entered Atlas in 2020. A June 2023 explanation described Python models, solver APIs, Excel interfaces, and cloud parallelization. 19 32 | Extensibility and access to standard optimization were part of the platform before the agentic branding. |
| 2024 | Optilogic acquired INSIGHT and its network-design heritage, extended the Gurobi relationship, and launched Leapfrog in November to perform model/data operations through natural language. 28 19 20 | Leapfrog’s disclosed contribution was access and manipulation, including SQL-oriented work. The solver remained Gurobi; the partnership does not transfer credit for Gurobi’s numerical engineering. |
| 2025 | The $40 million Series B announcement targeted further platform development. November’s DataStar launch promoted autonomous data preparation, 95% faster modeling, and production cost/inventory reductions. 27 21 | The release’s Bain quotation described expected future time savings. It did not provide a measured workflow or a customer-specific reconciliation for the headline percentages. |
| June 2026 | Ada became generally available after an early-adopter program involving more than forty customers. The release says teams retain strategy, validation of every output, and final decisions. 22 | Current documentation confirms model-writing and tool-execution capabilities, but no published cohort establishes the full claimed reduction in modeling effort. |
| Late 2026 | MCP extends Ada into other assistants. 11 | A broader interface and additional users do not establish that specialist maintenance has ceased to constrain throughput. |
The roadmap has produced working tools and useful documentation. Its weakness is repeated categorical language about removing the data bottleneck or transforming months of work into a day without a corresponding account of the work left over. The Dendro and Ada manuals are more candid: models require validation, objectives require choices, and the user retains substantial responsibility.
Software bill of materials
Optilogic’s visible architecture has a common data foundation and several distinct computational services. The public record does not establish the complete deployment stack.
| Component | Evidence and scope | Maintenance consequence |
|---|---|---|
| PostgreSQL | Cosmic Frog models and DataStar project databases use PostgreSQL, with Anura and Starburst schemas respectively. 15 | A common database technology helps integration; compatible schemas and decision semantics still require explicit transformations. |
| Gurobi | Commercial MILP solver used by Neo. 2 19 | Solver licensing, version changes, and formulation quality affect cost and behavior. Optilogic owns the supply chain formulation, not the underlying solver invention. |
| Python and SQL | Atlas, DataStar tasks, and custom model utilities execute customer logic. Extra Python libraries can be supplied through requirements files. 12 13 | Customer dependencies add patching, reproducibility, and execution-isolation obligations. |
| React and TypeScript | A 2026 Optilogic frontend vacancy specifies React, TypeScript, Redux/RTK Query, and Vite for its flagship product. 18 | This identifies the application interface stack; it does not disclose the numerical engine implementation. |
| OpenAI model API | Ada’s documentation identifies OpenAI as its current AI provider and describes task-dependent transmission of metadata or data slices. 9 | Confidentiality and operating cost extend beyond Optilogic’s databases. |
| Parallel simulation and optimization jobs | Run settings expose resources, concurrent replications, and separate simulation job sizing. 2 | More scenarios consume additional compute and produce more outputs to retain, inspect, and reproduce. |
The strongest architectural feature is the inspectable connection between model tables and engines. The unresolved burden is the combination of customer-authored code, configurable numerical methods, multiple simultaneous runs, and generated artifacts. Cloud execution moves that infrastructure off the customer’s machines; it does not remove its maintenance or cost.
Security: Python requires an enforced boundary
The Run Python task accepts custom scripts and additional dependencies; its guidance asks users to test on copies of their data. General-purpose code operating on business data needs stronger protection than that advice. A mistaken script, unsafe generated code, or compromised package must encounter enforced limits on accessible data, secrets, network connections, and production changes. The public instructions do not explain those limits or a controlled promotion and rollback mechanism. 12
Ada’s documentation is unusually explicit about one weakness: its prompt-injection safeguards are instructions and do not constitute a technical barrier. The same appendix identifies external model processing and says data is not used for model training. Training policy does not prevent an injected instruction from causing an inappropriate authorized action or exposing data during a task. 9
The platform has useful controls elsewhere. Teams define shared workspaces and record actions. App keys are documented as nonexpiring, whereas API keys last an hour. Manual database snapshots persist until removed, and daily zone-redundant PostgreSQL server backups are retained for thirty-four days. Those mechanisms improve access management and recoverability, but neither snapshots nor logs prevent data exfiltration. 29 16 17
The design question, consistent with Lokad’s security principles, is what damage remains possible after a user or agent makes a serious mistake. Certification and repeated human approval do not answer it. The missing containment detail is material because customization and generated code are central product features.
Economic accountability
The public EULA makes correction of nonconforming software the exclusive remedy for failure, excludes lost profits and lost data, and generally caps liability at the preceding twelve months of license fees. It also states that a signed license agreement prevails where terms conflict. These are the published default terms, not a disclosure of every negotiated customer agreement. 26
That remedy addresses software conformity rather than the return on a network redesign. A model can run correctly and recommend an economically poor change because its assumptions are wrong. The commercial proposition needs an accountable process for detecting that failure, assigning responsibility for the assumptions, and correcting the model.
Customer participation in validation is necessary. It becomes an asymmetry when the product receives credit for modeled savings while all unverified assumptions and execution costs remain outside the calculation. Optilogic’s cases need clearer separation of candidate benefits, implemented changes, realized returns, and continuing modeling costs.
Supply chain score
Supply chain depth
| Criterion | Score |
|---|---|
| Economic framing | 6/10 |
| Decision end-state | 6/10 |
| Conceptual sharpness on supply chain | 7/10 |
| Freedom from obsolete doctrinal centerpieces | 4/10 |
| Robustness against KPI theater | 4/10 |
Average: 5.4/10
Economic framing — 6/10. Network costs, asset choices, and operational trade-offs are central. The weakness is translating monetary outcomes into normalized weighted criteria whose relative value can shift during search. That can change the selected policy without a corresponding economic reason. 4
Decision end-state — 6/10. The platform produces network configurations and operating-policy recommendations with identifiable implementation consequences. The final selection and organizational execution remain outside the numerical result; a scenario portfolio is not itself a deployed decision process. 1 3
Conceptual sharpness on supply chain — 7/10. A structurally attractive network can operate badly under the wrong policies. Optilogic gives that problem an explicit computational treatment; validating the consequences of policy changes remains necessary. 3 31
Freedom from obsolete doctrinal centerpieces — 4/10. Classical network formulations, reorder-policy families, service targets, and weighted scores still organize much of the computation. Flexible configuration can change them, but the standard framework does not inherently seek the best monetary decision under uncertainty. 2 4
Robustness against KPI theater — 4/10. The detailed retail case explains its levers and avoids adding isolated savings. Its historical cost fit still cannot validate the advertised future savings, while broad modeling-speed percentages lack a complete measured workload. 24 21
Decision and optimization substance
| Criterion | Score |
|---|---|
| Probabilistic modeling depth | 6/10 |
| Distinctive optimization or ML substance | 5/10 |
| Real-world constraint handling | 7/10 |
| Decision automation and labor productivity | 5/10 |
| Resilience under real operational complexity | 6/10 |
Average: 5.8/10
Probabilistic modeling depth — 6/10. Simulation can represent uncertainty in demand and supply, and policy search can use its results. Public evidence does not establish calibrated joint forecasts, dependence assumptions, or predictive validation of the resulting economic outcomes. 3 6 7
Distinctive optimization or ML substance — 5/10. The engines perform actual mathematical and simulation-based work. Gurobi is an external solver, and evolutionary search is a standard technique; the distinctive engineering must reside in the supply chain representation and its demonstrated results. The published record does not isolate that contribution. 19 31
Real-world constraint handling — 7/10. The system can represent structural choices, operating policies, delivery windows, and event timing. The practical ceiling is the selected model boundary: aggregation and restricted search ranges can remove costly interactions before computation begins. 3 5 24
Decision automation and labor productivity — 5/10. Reuse and automated preparation can remove repetitive work. The unresolved requirement is an end-to-end labor measure: faster answers must translate into more implemented improvements without a matching increase in maintenance and validation effort. 23 22
Resilience under real operational complexity — 6/10. Editable model data, scripts, and policy search provide means to revise a faulty representation. The missing evidence is a production feedback process that consistently turns observed failures into tested improvements in objectives and available decisions, rather than additional scenarios alone. 13 15
Product and architecture integrity
| Criterion | Score |
|---|---|
| Architectural coherence | 7/10 |
| System-boundary clarity | 7/10 |
| Security seriousness | 3/10 |
| Software parsimony and ownership cost | 4/10 |
| Compatibility with programmatic and agent-assisted operations | 7/10 |
Average: 5.6/10
Architectural coherence — 7/10. The shared database foundation and documented transformations connect the main applications intelligibly. Separate engines still need consistent interpretation of costs, time, and uncertainty; sharing tables does not ensure that consistency. 15 2
System-boundary clarity — 7/10. Documentation identifies model databases, transformation projects, external AI processing, and connector permissions. These disclosures make important boundaries inspectable, although the runtime limits around customer code remain insufficiently explained. 15 11 12
Security seriousness — 3/10. General-purpose code and installable dependencies operate on valuable model data, while enforced containment is not documented. Ada’s candid acknowledgment that instructions are not a technical barrier makes the need for external enforcement especially clear. 12 9
Software parsimony and ownership cost — 4/10. Parallel search, maintained transformations, custom code, and metered agent use all incur ongoing costs. The documents explain some consumption mechanisms but do not reconcile them with the broad productivity and savings claims. 30 13
Compatibility with programmatic and agent-assisted operations — 7/10. APIs, direct database access, Python utilities, and reusable agent artifacts allow more than manual screen operation. That flexibility is valuable only when code, permissions, and model changes are governed and economically tested. 15 13 10
Technical transparency
| Criterion | Score |
|---|---|
| Public technical documentation | 8/10 |
| Inspectability without vendor mediation | 7/10 |
| Portability and lock-in visibility | 6/10 |
| Implementation-method transparency | 7/10 |
| Evidence density behind technical claims | 5/10 |
Average: 6.6/10
Public technical documentation — 8/10. The manuals expose numerical methods, schemas, policy parameters, score construction, and operational controls. Missing forecast-validation and execution-security details are specific gaps within an otherwise substantial technical record. 2 4 12
Inspectability without vendor mediation — 7/10. Users can inspect data, customer scripts, and exported optimization formulations. Reproducing platform behavior still depends on proprietary engines and services, and the EULA restricts reverse engineering. 2 13 26
Portability and lock-in visibility — 6/10. PostgreSQL access and ordinary Python make extraction and reuse practical. A portable dataset or script is not a portable simulation engine, model semantics, or commercial solver entitlement. 15 19
Implementation-method transparency — 7/10. Guides explain how to choose adjustable factors, configure objectives, maintain workflows, and establish a simulation baseline. They reveal the work involved more clearly than the claims of near-instant modeling, but do not price the full continuing effort. 5 4 14
Evidence density behind technical claims — 5/10. Product mechanisms are documented in depth. The evidence is thinner on whether the predictions remain accurate after structural changes and whether the AI-driven process delivers the headline speedup at comparable decision quality. 24 21
Vendor seriousness
| Criterion | Score |
|---|---|
| Technical seriousness of public communication | 4/10 |
| Technology roadmap integrity | 5/10 |
| Conceptual sharpness | 6/10 |
| Economic accountability | 4/10 |
| Defensibility in an agentic-software world | 6/10 |
Average: 5.0/10
Technical seriousness of public communication — 4/10. The detailed manuals coexist with sweeping claims about eliminating data bottlenecks and providing complete confidence in design. Historical fit, simulation precision, and real economic reliability are not interchangeable. 21 24 1
Technology roadmap integrity — 5/10. The sequence from Python extensibility through Leapfrog, DataStar, and Ada has delivered identifiable capabilities. Follow-through on the repeated promise of radically less modeling labor remains inadequately measured. 32 20 22
Conceptual sharpness — 6/10. A detailed model must retain the economic meaning of its outputs. Risk and utility scores remain an inadequate substitute for a consistent monetary evaluation unless the modeler supplies that discipline. 4 8
Economic accountability — 4/10. Named implemented benefits support commercial substance. The public evidence still lacks a full return-after-costs account, while the default contractual remedy concerns software conformity rather than the economic performance of a recommendation. 23 26
Defensibility in an agentic-software world — 6/10. The simulation environment, documented schemas, and deployed modeling workflows offer more substance than an MCP connector. Long-term value depends on using agents to maintain reliable decision models and reduce specialist effort, rather than merely multiplying analyses and presentations. 31 15 11
Sources
All sources were accessed on November 4, 2026. Dates identify publication where available.
Cosmic Frog. Product scope, applications, and current claims.
[2] Running Models & Scenarios in Cosmic Frog
Running Models & Scenarios in Cosmic Frog. Solver methods, exported formulations, simulation controls, and Dendro variants.
[3] Getting Started with Dendro
Getting Started with Dendro. Simulation scope, validation prerequisites, and relationship to network optimization.
[4] Dendro: Output Factors Guide
Dendro: Output Factors Guide. Utility weights, normalization, and dynamic rescaling.
[5] Dendro: Input Factors Guide
Dendro: Input Factors Guide. Adjustable policy variables, scope, ranges, and search configuration.
[6] Throg: Simulation Distribution Syntax
Throg: Simulation Distribution Syntax. Distribution inputs and empirical histograms.
[7] Adding Demand (Simulation)
Adding Demand (Simulation). Order-level demand and generated profiles.
[8] Custom Risk Profiles in Cosmic Frog
Custom Risk Profiles in Cosmic Frog. Weighted risk categories and configuration.
[9] Getting Started with Ada & Agentic AI
Getting Started with Ada & Agentic AI. Agent capabilities, external model processing, and explicit safety limitations.
[10] AI Agents: Architecture and Components
AI Agents: Architecture and Components. Tool-execution loop, logs, and delegation.
[11] The Optilogic MCP Connector
The Optilogic MCP Connector. Interface, permissions, approvals, and data handling.
Run Python Task. Practitioner scripts, dependencies, and testing guidance.
[13] Creating Cosmic Frog Model Utilities
Creating Cosmic Frog Model Utilities. Editable and shareable model utilities.
DataStar Overview. Data workflow structure and application scope.
[15] DataStar: Data Integration
DataStar: Data Integration. Database integration, refresh, and archival responsibilities.
[16] Generating App and API Keys
Generating App and API Keys. App-key and API-key lifetimes.
[17] Backups & Retention Explained
Backups & Retention Explained. Database snapshots and server recovery retention.
[18] Optilogic Senior Software Engineer, Zagreb
Optilogic Senior Software Engineer, Zagreb. Employer-attributed frontend requirements for the flagship platform.
[19] Optilogic extends Gurobi partnership
Optilogic extends Gurobi partnership. Published 2024-11-07. Solver provenance and partnership history.
Leapfrog AI launch. Published 2024-11-19. Natural-language model/data manipulation launch.
DataStar launch. Published 2025-11-20. Data-preparation launch and productivity claims.
Ada launch. Published 2026-06-03. General availability, early adopters, and retained human validation.
[23] Supply Chain Design at Castrol
Supply Chain Design at Castrol. Published 2026-10-30. Named implementation, reported benefits, and modeling bottleneck.
[24] Store Network Optimization
Store Network Optimization. Published 2026-05-20. Partner-authored modeled program, historical fit, and scope limits.
[25] Global automotive supplier cost savings
Global automotive supplier cost savings. Published 2024-08-23. Anonymous study, scenario work, and savings claims.
[26] End User License Agreement
End User License Agreement. Default remedies, liability, and signed-agreement precedence.
[27] Optilogic closes $40m Series B
Optilogic closes $40m Series B. Funding and development priorities.
INSIGHT acquisition. Acquisition and inherited product history.
[29] Optilogic Teams: User Guide
Optilogic Teams: User Guide. Shared workspaces, roles, and activity records.
[30] Understanding Ada Credits
Understanding Ada Credits. AI metering, pool exhaustion, and purchase process.
[31] Dendro: Genetic Algorithm Guide
Dendro: Genetic Algorithm Guide. Network-wide policy search and its implementation.
[32] Atlas extensible platform Q&A
Atlas extensible platform Q&A. Published 2023-06-16. Earlier Python/API/Excel extensibility and cloud execution.