Go back to Market Research
DecisionBrain develops planning, scheduling, routing, and resource-allocation applications for manufacturing, supply chain, logistics, workforce management, and maintenance. Its DB Gene platform provides data management, scenarios, interfaces, and access controls. DBOS executes computational jobs, while DB Gene Studio supports application development through configurable dashboards, notebooks, and generated data models. Customers obtain tailored applications and associated development and support services. 1 2 13 14
Overall supply chain score: 5.6/10
| Dimension | Score |
|---|---|
| Supply chain depth | 5.4/10 |
| Decision and optimization substance | 5.4/10 |
| Product and architecture integrity | 5.2/10 |
| Technical transparency | 6.6/10 |
| Vendor seriousness | 5.4/10 |
DecisionBrain has substantial engineering content: inspectable development manuals, identifiable optimization methods, research contributions, and customer applications that produce operational decisions. Its strongest evidence concerns specific routing, scheduling, and pricing problems. It does not establish a general engine that selects economically coherent supply chain decisions across uncertain demand, replenishment dates, production yields, and shared resources.
The central weakness is the gap between a flexible optimization platform and an adequate model of the business. DecisionBrain normally favors mixed-integer linear formulations, with other methods available when needed. Its own supply chain writing explains why fixed-input optimization fails under uncertainty. The missing connection is a demonstrated production method that incorporates those uncertain futures into decision selection without sacrificing economic fidelity or making maintenance prohibitively expensive. 3 6
DecisionBrain versus Lokad
DecisionBrain builds a custom application around the customer’s planning problem. Its teams can combine commercial solvers, specialized algorithms, rules, and user interfaces. Business users then operate the application, compare scenarios, and intervene according to the workflow implemented for that customer.
Lokad’s inventory optimization service organizes recurring decisions around their expected financial contribution under uncertainty. Its Supply Chain Scientists maintain the decision logic, including the economic assumptions and operational constraints. The distinction is not customization: both approaches require substantial knowledge of the customer’s business. It is which abstractions structure the resulting software and how uncertainty enters the decisions.
Consider a manufacturer deciding whether to produce another batch before a supplier delivery has arrived. A fixed delivery date can make the batch feasible on paper while concealing the cost of a late receipt. Adding alternative schedules helps a planner examine the risk. Selecting the action requires valuing the possible receipt dates, subsequent demand, capacity commitments, and consequences of waiting together.
DecisionBrain provides infrastructure in which developers could build such a calculation. Its public supply chain offer instead emphasizes service targets, safety stocks, and scenario comparisons. Lokad’s approach, explained in Introduction to Supply Chain, starts with uncertain outcomes and monetary trade-offs. The practical comparison is the quality and maintainability of the delivered decision logic, including the labor needed to keep it economically relevant. 4
What the optimization actually computes
Linearization exposes the main modeling risk
The technical FAQ states that DecisionBrain prefers converting problems into mixed-integer formulations where possible. It also names nonlinear optimization, constraint programming, metaheuristics, decomposition, and custom hybrid algorithms. The firm therefore offers a broader toolkit than one solver wrapper. Its multi-objective options include weighted objectives, priority ordering, and Pareto comparisons. 3
For supply chain, the preference for linearization remains a red flag. Minimum orders, substitutions, expiry, scarce capacity, and customer responses create discontinuous and interacting economic effects. A model can represent selected features with integer variables, but every representation involves choices about which relationships to retain. A precise solution to an impoverished formulation can be precisely wrong commercially.
Uncertainty makes this harder. Replicating a deterministic model across demand, receipt-date, yield, and capacity scenarios multiplies an already difficult search space. Decomposing it into manageable pieces can sever the interactions that justified system-level optimization. More processing power does not restore an omitted economic relationship.
The important engineering question is consequently broader than the solver’s runtime or remaining optimality gap: how cheaply can the team discover that its formulation is wrong, change the decision problem, and validate the revised policy against operational outcomes? Holimization develops this distinction between solving a model and improving the model itself.
DecisionBrain recognizes uncertainty more clearly than its product pages specify it
Justin Clark’s June 2025 article explicitly criticizes fixed demand, capacity, and linear assumptions. It calls for modeling demand volatility, lead-time uncertainty, and capacity variation, and supplies a simplified notebook contrasting fixed-input and variation-based plans. It also says that repeatedly refreshing a deterministic model does not cure the underlying problem. 6
That diagnosis is sound. The public forecasting page, however, remains at the level of historical data, demand drivers, machine learning, and segmentation. It does not specify calibrated predictive distributions, dependencies, or out-of-sample evaluation. The inventory page targets safety stock, reorder points, replenishment strategies, and customer service levels while acknowledging variable supply reliability. 4 5
Acknowledging a late supplier is different from assigning plausible receipt dates probabilities and using them to select a purchase or production quantity. The published material does not trace that complete calculation. Nor does it show how forecast uncertainty, rather than a collection of planner-selected scenarios, enters the production applications.
Production examples expose meaningful constraints
The Cooperl case describes a one-to-three-week plan connecting incoming pigs with demand for meat cuts and processed products. It includes transformation rules, capacity, freshness, and substitutions between grades. Avoiding freezing and downgrading has an identifiable financial purpose. The published case nevertheless describes deployment as ongoing and benefits as expected. It reports neither realized margin improvement nor a joint uncertainty model. 7
The packaging case, under the Ajover URL, couples an all-plant master plan with a scheduling engine. Materials, tools, storage, shelf life, transport costs, and intermediate products appear in the formulation. The scheduler follows inventory targets from the master plan. The case reports preliminary results during final implementation, without quantified savings. 8
These are concrete operational problems. Their architectures also expose a limit: coordination between a master plan and a subordinate schedule does not establish that both stages select the best economic policy under uncertainty. A schedule can meet its inherited targets while those targets allocate capacity or inventory poorly.
Customer outcomes and the work that remains
Toyota: distinguish inbound improvement from outbound automation
DecisionBrain’s January 2022 Toyota milk-run account reports transportation costs falling 2–10%, typically 8%, compared with preceding months; occasional reductions reached 15%. Monthly planning fell from 2.5 days to under an hour. The vendor estimates eight-month payback and identifies a project effort of roughly 2.5 consultants for ten months. 10
The algorithm deliberately limits disruption: it preserves selected routes and improves others through local changes. Planners approve each suggestion; global search is reserved for planning routes for a new model. That is a specific operating compromise, not comprehensive autonomous optimization.
A separate April 2025 outbound-logistics case describes automatic schedule updates about every 15 minutes and a monthly tactical calculation reduced to 20 minutes. Daily execution responds to actual orders and events; the monthly baseline uses average daily orders. 9
Together, these cases establish that software can remove considerable planning work and automate selected recalculations. They do not quantify all recurring labor, maintenance expenses, or the marginal return from anticipating uncertainty instead of reacting after events arrive. The historical savings also cannot establish the contribution of a newly introduced LLM.
Clearance pricing: meaningful economics, incomplete attribution
The June 2026 anonymous retail case reports a 4–6% increase in clearance revenue and approximately €35 million additional profit during one campaign. It describes live pilots, subsequent expansion, and a later review of the model, solver settings, architecture, and data processing. Crucially, it considers the labor cost of changing price labels alongside sales and margin. 11
That cost changes the decision: a theoretically attractive markdown can be uneconomic to execute. This is the kind of operational detail that gives an optimization model substance.
The case omits the customer, deployment dates, experimental protocol, and the division of work between original development and the later technical review. Consequently, the headline cannot establish how much of the benefit arose from DecisionBrain’s own engineering, which platform version produced it, or what remained after ongoing costs.
Technology history and delivery
DecisionBrain has maintained its optimization infrastructure and research program across several technology waves. Its use of the AI label still requires separating actual algorithms from broad claims about intelligent or autonomous operations.
| Period | Public record | What followed |
|---|---|---|
| 2013–2020 | The IBM partnership timeline begins with custom analytics applications and culminates in IBM selling an OEM version of DecisionBrain’s platform as DOC 4.0. | A maintained product lineage is visible in later manuals and releases. 22 |
| September 2020 | The AIDA consortium announces research combining learning, automation, and adaptable decision systems. | DecisionBrain-linked work subsequently produces published methods for explaining workforce scheduling decisions. 23 24 |
| 2022 | Workforce material places mathematical scheduling under the AI heading. | The described constraints and objectives concern bounded optimization, rather than general reasoning. 26 |
| February 2024 | DB Gene 4.1.0 adds Python data integration, interface changes, and dependency upgrades. | The release history continues with documented fixes and platform changes through October 2026. 21 20 |
| 2024–2025 | A research collaboration investigates graph-neural-network guidance for lot-sizing reoptimization. | The reported method fixes predicted stable variables and reoptimizes the remainder; its published scope is numerical experimentation. 25 |
| 2025–2026 | Agentic AI essays discuss event interpretation, model updates, and supervision. Studio adds generative data modeling and notebook integration. | These additions accelerate application construction and interaction; measured autonomous supply-chain outcomes remain limited. 14 27 |
The AIDA follow-through matters. The 2024 paper has an author affiliated with DecisionBrain and develops contrastive explanations for workforce scheduling and routing. It evaluates actual algorithms, rather than merely invoking explainable AI. The lot-sizing work similarly tackles a specific computational bottleneck. Neither establishes a deployed stochastic supply chain engine, but both are identifiable research contributions.
The November 2025 agentic essay describes a toy implementation in which an LLM translates events into numerical changes for an optimizer. Its disclosed failures include hallucinated changes and missed signals. Those errors can silently change the problem being solved, so reliable deployment requires validation outside the language model. 27
Bill of software materials
Public development and deployment documentation provides stronger evidence here than generic technology lists in recruitment. The current product-manager posting also distinguishes developers, business analysts, and operational planners as separate users of the same platform. 29
| Layer | Attributable components | Operational implication |
|---|---|---|
| Application services | Java/Spring services, Angular frontend, and generated application components; dependency changes appear in release notes. | Custom extensions must remain compatible with platform upgrades. 20 21 |
| Data persistence | PostgreSQL stores scenario data; MongoDB stores metadata, properties, and application elements in the documented deployment. | Backups and restoration must preserve consistency across two databases. 15 |
| Messaging and identity | RabbitMQ and Keycloak appear in the deployment instructions and current dependency updates. | Message delivery, authentication, and data services require coordinated operation. 15 20 |
| Computational jobs | Packaged Java and Python workers execute application logic; CPLEX and Gurobi are supported solvers. | Model code, language dependencies, and commercial licenses add their own lifecycle costs. 2 16 |
| Development interfaces | JupyterHub/notebooks and Drools rules in Studio. | Analysts gain flexibility, with additional code review, execution-control, and maintenance requirements. 14 |
| Deployment | Docker locally; Kubernetes or OpenShift for larger deployments. | Installation portability does not remove infrastructure administration. 2 15 |
The two-database design creates a concrete ownership cost. The manual requires synchronized backup and restoration even though the volumes are handled separately. A partially restored application can have scenario metadata that no longer matches its underlying records. This is more informative than counting logos: the architecture creates a consistency obligation that someone must implement and test.
The platform also does useful infrastructure work. DBOS shares computation and solver licenses, monitors executions, and supports replay. Reusing those facilities can avoid building them separately for every application. The relevant comparison is the total lifecycle cost of the complete deployment, not whether its components are individually established products.
Configuration maintenance and total cost
DecisionBrain’s advertised reduction of more than 70% in application-development effort lacks a published cohort and calculation. Reusable interfaces, data services, and execution infrastructure explain how savings could arise. They do not quantify the remaining cost of formulating the optimization problem, maintaining integrations, investigating bad recommendations, and upgrading custom code. 1
Its delivery method provides short development iterations, customer access to project tracking, working software deliveries, and support after deployment. It also describes monitoring inputs, outputs, and usage to improve returns. These mechanisms create opportunities to revise the model rather than freeze it at implementation. The commercial scope and price of those revisions remain project-specific. 12
The distinction between technical and economic maintenance is important. Replacing a dependency or restoring a service keeps the application running. Revising the penalty for a shortage, the treatment of supplier delays, or the cost of a production change keeps its decisions relevant. A successfully executed job can still encode an obsolete business assumption.
DecisionBrain’s June 2026 essay explicitly identifies this decay of assumptions. That makes the absence of a measured maintenance burden more consequential: the vendor recognizes the problem, but its public materials do not show the staff effort and cost required to control it across deployed applications. 28
The FAQ offers subscriptions, perpetual licenses with maintenance, and pricing based on customer-specific business metrics. Full ownership cost must therefore include application delivery, solver licenses, hosting, support, internal analysts, and continued model development. A faster solver or lower initial development bill addresses only part of that expense. 3
Security: application permissions do not settle code confinement
DecisionBrain publishes mechanisms beyond certification claims: encrypted transport and storage, dedicated customer clusters, Keycloak-based identity, role-based controls, and vulnerability scanning. Its permissions manual considers the user, job scope, operation, and target application element. API keys inherit their creator’s authorizations and can be deleted. These are inspectable access boundaries. 3 17 18 19
The harder boundary concerns custom execution. Studio explicitly supports Python algorithms and notebooks, including embedded visualizations and data checkers. Worker documentation describes packaged code receiving scenario data and returning results through adapters. Packaging provides an execution structure; it does not by itself constrain what a compromised Python dependency can read, contact, or modify. 14 16
The reviewed public documentation does not specify a comprehensive policy for notebook and worker network access, secrets, dependency installation, or isolation between differently trusted code. Those controls matter when analytical users can execute code against operational information. The security claim remains incomplete at precisely the boundary introduced by flexible programming.
DecisionBrain’s security FAQ also claims that its listed tools reduce security risks by around 90%, without identifying the benchmark or defining the risk being measured. That number provides no basis for judging resistance to a compromised package, stolen credential, or unauthorized production action. Certifications cannot supply the missing threat model. 19
Productivity and economic accountability
The relevant productivity question is how much recurring work disappears after accounting for model maintenance, exceptions, and approvals. Generating a data model in natural language can reduce application-construction effort. A dashboard can shorten inspection. Neither establishes that the organization needs less labor to make and execute its recurring supply chain decisions.
DecisionBrain’s operational cases show different degrees of automation, so a single platform-wide autonomy label would be misleading. An application that recomputes schedules automatically has a different labor profile from one that presents each route adjustment for approval. The distinction should remain visible in deployment metrics.
The service methodology gives DecisionBrain responsibility for monitoring operation and helping improve outcomes. Public case studies still emphasize successful projects without publishing a balanced process for investigating economically harmful recommendations. A useful accountability arrangement must distinguish an incorrect business model from poor implementation, bad input data, and a customer override. Otherwise, an unfavorable outcome can always be assigned to a factor outside the optimization calculation. 12
Supply chain score
The overall score is the arithmetic mean of the 25 subscores below. Each dimension carries equal weight.
Supply chain depth
| Criterion | Score |
|---|---|
| Economic framing | 6/10 |
| Decision end-state | 7/10 |
| Conceptual sharpness on supply chain | 5/10 |
| Freedom from obsolete doctrinal centerpieces | 4/10 |
| Robustness against KPI theater | 5/10 |
Average: 5.4/10.
Economic framing — 6/10. Routing, pricing, and production examples connect decisions to identifiable costs and margins. Their economic scope is project-specific; a common criterion across demand, supply uncertainty, capital, and competing decisions is not demonstrated. 7 9 11
Decision end-state — 7/10. The applications produce schedules, routes, production quantities, and pricing recommendations. These are operational outputs, although approval and execution boundaries differ by deployment. 7 9
Conceptual sharpness on supply chain — 5/10. The variability essay identifies a central defect of conventional planning. The product descriptions do not establish how that insight becomes calibrated uncertainty and economic decision selection. 6
Freedom from obsolete doctrinal centerpieces — 4/10. Service targets, stock policies, weighted objectives, and scenario selection remain prominent. Custom development can revise them, but flexibility alone does not make their economic assumptions sound. 3 4
Robustness against KPI theater — 5/10. Several cases provide interpretable operational measurements. Preliminary production cases, anonymous financial claims, and broad development-effort promises have less complete measurement and attribution. 7 8 11 1
Decision and optimization substance
| Criterion | Score |
|---|---|
| Probabilistic modeling depth | 3/10 |
| Distinctive optimization or ML substance | 6/10 |
| Real-world constraint handling | 7/10 |
| Decision automation and labor productivity | 6/10 |
| Resilience under real operational complexity | 5/10 |
Average: 5.4/10.
Probabilistic modeling depth — 3/10. Public material recognizes demand and supply variability, but does not specify joint future distributions or their use in selecting decisions. Illustrative scenarios and rapid replanning leave that gap open. 5 6
Distinctive optimization or ML substance — 6/10. The published explanation algorithms and reoptimization research demonstrate contributions beyond integrating a solver. Their narrow scope and the default linearization approach limit the supply-chain-wide inference. 24 25
Real-world constraint handling — 7/10. The cases expose meaningful interactions among production, storage, transport, expiry, and execution. The remaining issue is economic fidelity under uncertainty, rather than whether constraints can be entered. 7 8 9
Decision automation and labor productivity — 6/10. Toyota provides measurable workload reduction and a separate example of automatic recalculation. Comparable accounting for all maintenance and approval labor is absent from the wider platform claims. 9 10
Resilience under real operational complexity — 5/10. Delivered applications and specialized search methods support practical capability. They do not establish affordable scaling when a model must retain many coupled uncertain states and undergo repeated economic revision. 3 12 25
Product and architecture integrity
| Criterion | Score |
|---|---|
| Architectural coherence | 5/10 |
| System-boundary clarity | 6/10 |
| Security seriousness | 4/10 |
| Software parsimony and ownership cost | 4/10 |
| Compatibility with programmatic and agent-assisted operations | 7/10 |
Average: 5.2/10.
Architectural coherence — 5/10. Data, scenarios, access controls, and computational workers have documented roles. The distributed services and multiple persistence layers create consistency and upgrade obligations beyond the optimization model itself. 15
System-boundary clarity — 6/10. Manuals explain the separation between application data, worker execution, and permissions. Solution-specific economic boundaries and the authority of code executed through analytical interfaces are less fully specified. 16 17
Security seriousness — 4/10. Detailed access controls provide substance, while practitioner-code confinement remains insufficiently documented. The unsupported numerical risk-reduction claim weakens the security argument further. 19
Software parsimony and ownership cost — 4/10. Shared infrastructure and license utilization can reduce duplication. The full stack, custom code, and continuing model work create a substantial maintenance obligation that the development-saving headline does not measure. 1 2 13 15
Compatibility with programmatic and agent-assisted operations — 7/10. APIs, packaged computational tasks, and programmable application logic support automation without requiring screen imitation. Generative interfaces still need bounded authority and measured decision quality. 16 18
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. Versioned manuals expose deployment, data structures, workers, permissions, and interfaces. Current release notes reveal actual maintenance. The economic models delivered to customers are less visible. 15 16 20
Inspectability without vendor mediation — 7/10. Developers can inspect substantial implementation instructions and research papers without a demonstration. They cannot reproduce the main customer economic results from the published information. 15 16 24 7 9 11
Portability and lock-in visibility — 6/10. Container deployment and multiple solver options provide flexibility. Applications still depend on the platform’s service contracts, data conventions, libraries, and customer-specific extensions. 2 15 16
Implementation-method transparency — 7/10. The delivery method and manuals explain how applications are constructed and supported. Effort is more visible than in a turnkey marketing account, although ongoing commercial costs remain undisclosed. 12 13
Evidence density behind technical claims — 5/10. Detailed engineering evidence supports the platform’s existence and behavior. Broader claims about optimal decisions, productivity, and economic returns exceed what the public validation establishes. 1 3 7 11 24
Vendor seriousness
| Criterion | Score |
|---|---|
| Technical seriousness of public communication | 5/10 |
| Technology roadmap integrity | 7/10 |
| Conceptual sharpness | 5/10 |
| Economic accountability | 4/10 |
| Defensibility in an agentic-software world | 6/10 |
Average: 5.4/10.
Technical seriousness of public communication — 5/10. Concrete manuals and candid experimental writing coexist with overbroad optimization language and an unjustified security percentage. The strongest material is specific about method and scope. 3 19 24 27
Technology roadmap integrity — 7/10. Maintained releases and research outputs provide evidence of follow-through. New generative interfaces have not yet supplied comparable public evidence of recurring operational gains. 20 24
Conceptual sharpness — 5/10. DecisionBrain understands several failures of fixed models and the need to revise assumptions. Its default formulation strategy and target-driven inventory offer leave those insights only partially implemented in the disclosed approach. 3 4 6
Economic accountability — 4/10. The vendor describes support for outcomes after deployment and publishes some quantified results. Full cost reconciliation and a method for assigning responsibility when accepted recommendations lose money remain unclear. 9 11 12 13
Defensibility in an agentic-software world — 6/10. Domain modeling, computational methods, and maintained decision applications are harder to replace than dashboards alone. Standard application scaffolding and conversational configuration face greater substitution pressure from general-purpose coding agents. 13 24 27
Sources
Sources were accessed on November 4, 2026. Publication dates and deployment periods are distinguished where the source provides them. Live links remain where a matching archived capture has not been verified.
[1] DB Gene development platform
DecisionBrain. Published: Undated. Application components and the development-effort claim.
[2] DecisionBrain Optimization Server
DecisionBrain. Published: Undated. Job execution, resource sharing, deployment options, and solver interfaces.
[3] Technical and implementation FAQ
DecisionBrain. Published: Undated. Method choices, deployment, implementation, and pricing models.
[4] Supply and inventory planning
DecisionBrain. Published: Undated. Inventory policies, service targets, and supply reliability.
[5] Forecasting and demand planning
DecisionBrain. Published: Undated. Forecasting scope and the level of public method disclosure.
[6] Why supply chain optimization often falls short
DecisionBrain. Published: 2025-06-13. Justin Clark’s critique of deterministic inputs and illustrative uncertainty notebook.
[7] Cooperl production planning case
DecisionBrain. Published: 2025-06-06. Production constraints, planning horizon, and explicitly expected benefits.
[8] Packaging planning and scheduling case
DecisionBrain. Published: Undated. Master planning, subordinate scheduling, and preliminary implementation status.
[9] Toyota outbound logistics case
DecisionBrain. Published: 2025-04-07. Automatic schedule refresh, monthly baseline, and computation-time result.
[10] Non-disruptive optimized milk-run planning
DecisionBrain. Published: 2022-01-26. Historical results, implementation effort, local search, and approval requirements.
[11] Clearance pricing optimization case
DecisionBrain. Published: 2026-06-29. Anonymous financial claim, execution costs, and later technical review.
[12] Professional services methodology
DecisionBrain. Published: Undated. Iterative delivery, customer involvement, monitoring, and support for outcomes.
[13] Application development and maintenance
DecisionBrain. Published: Undated. Development, maintenance, integration, and specialist services.
DecisionBrain. Published: Undated. Generative data modeling, notebooks, programming, rules, and user roles.
[15] DB Gene 4.12.2 deployment manual
DecisionBrain. Published: 2026-10-29. Deployment scope, component responsibilities, and coordinated database restoration.
[16] DB Gene 4.12.2 worker tasks
DecisionBrain. Published: 2026-10-29. Packaged worker execution and transfer of scenario data.
[17] DB Gene 4.12.2 permissions
DecisionBrain. Published: 2026-10-29. Authorization rules tied to users, jobs, operations, and application elements.
DecisionBrain. Published: 2026-10-29. API credential authority and lifecycle.
DecisionBrain. Published: Undated. Security mechanisms and the unsupported numerical risk-reduction assertion.
DecisionBrain. Published: 2026-10-30. Versioned changes through 4.12.2, including maintenance and dependency upgrades.
DecisionBrain. Published: 2024-02-20. Dated application, data integration, and library changes.
DecisionBrain. Published: Undated. Platform lineage and IBM OEM relationship.
DecisionBrain. Published: 2020-09-28. Consortium research objectives, including adaptation and explainability.
[24] User-centered explanations for workforce scheduling and routing
Authors’ published paper. Published: 2024. Lerouge, Gicquel, Mousseau, and Ouerdane; DOI 10.1111/itor.13594. Research accepted November 22, 2024, with DecisionBrain affiliation and acknowledgments.
[25] Mathieu Lerouge research and publications
Mathieu Lerouge. Published: Undated. Researcher’s account of the 2024–2025 collaboration and its experimental scope.
[26] Artificial intelligence for workforce optimization
DecisionBrain. Published: 2022-06-03. Pre-2023 use of the AI label for bounded workforce optimization.
[27] Making sense of agentic AI
DecisionBrain. Published: 2025-11-06. Justin Clark’s agent architecture and disclosed prototype failures.
[28] AI and enterprise planning
DecisionBrain. Published: 2026-06-15. Assumption maintenance and the limits of layering AI over existing planning.
[29] Product manager DB Gene, Bologna
DecisionBrain. Published: Undated. Employer-authored posting distinguishing developers, analysts, and operational users.