Search All Help Center Articles

Cosmic Frog’s network optimization engine (Neo) can now account for product shelf life, maturation time, and disposal out of the box with the addition of several fields to the Products input table. The age of product that is used in production, product which flows between locations, and product sitting in inventory is also reported in 3 new output tables, so users have 100% visibility into the age of their products across the operations.

In this documentation, we will give a brief overview of the new features first and then walk through a small demo model, which users can copy from the Resource Library, showing both shelf life and maturation time using 3 scenarios.

Overview

The new feature set consists of:

1. Four new fields (3 with their accompanying UoM fields) on the Products input table:
   
   • Shelf Life – use this field to model product expiry. The value entered indicates how long from when the product is produced it is available to fulfill demand. A product will expire once its shelf life runs out. Setting a shelf life will essentially add a constraint to the model on how long a product can be produced in advance of when it is served to the end-customer.
   • Maturation Time – use this field to set how long it takes from when the product is produced before it can be used to fulfill demand. Think for example of cheese that will take up space in inventory while ripening and cannot be sold before it has reached a certain age. Setting a maturation time also adds a constraint to the model of how long it needs to be in the network before it can be consumed.
   • Disposal Cost - specify the cost associated with taking expired product out of inventory.
   • Disposal Behavior - indicate when expired product is removed from inventory. There are 2 options which can be chosen from a drop-down list:
     
     • OnExpiry (the default) - expired product is removed from inventory at the end of the period it expired in.
     • EndOfHorizon - expired product is removed from inventory in the last period of the model.
2. Three new output tables:
   
   1. Optimization Production Age Summary – reports the age of product consumed by a BOM during production.
   2. Optimization Flow Age Summary – details the age of product of each flow.
   3. Optimization Inventory Age Summary – shows the age of product kept in inventory and captures disposals.

Please note that:

1. Shelf Life, Maturation Time, and Disposal will only have an impact in multi-period models; if set in a single-period model, they will be ignored. If periods of different lengths are used in a model, the most frequently occurring period length will be used for shelf life and maturation time calculations.
2. Users can enter Shelf Life and Maturation Time using any time-based unit of measure, e.g. days, weeks, months, etc. Based on the length of the periods in the model, shelf life and maturation time are converted to an integer multiple of periods. Fractional numbers are rounded to the nearest integer. For example:
   
   1. The length of the periods in a model is weeks, and shelf life is set to 33 days. This results in a shelf life of 33/7 = 4.71 weeks, which will be rounded to 5 weeks (= 5 periods).
   2. The length of the periods in a model is months, and maturation time is set to 9 weeks. This results in a shelf life of 9*7 days / 30 days = 2.1 months, which will be rounded to 2 months (= 2 periods).
3. The period in which a product is produced counts towards both the shelf life and maturation. For example:
   
   1. In a weekly model, a product’s shelf life is set to 4 weeks. If it is produced in period #3, its age will be 1 in period #3 and it can be consumed in periods 3 (age = 1), 4 (age = 2), 5 (age =3), and 6 (age= 4). If not consumed, it will have status = expired from period 7 onwards.
   2. In a monthly model, a product’s maturation time is set to 5 months. If it is produced in period #2, it needs to mature during periods 2, 3, 4, 5, and 6. As it becomes mature in period 6, it can be consumed (in a BOM or to fulfill demand) from period 6 onwards.
4. Products can have both shelf life and maturation time set. If this is the case, then shelf life has to be greater than or equal to the maturation time, otherwise the product expires before it is mature and cannot be consumed, resulting in an infeasible model run.
5. If there is initial inventory > 0 for any product-facility combination entered on the Inventory Policies table, the age of this product will be 1 in the first period of the model. If it has a shelf life of 5 days in a model with daily periods it can be consumed in periods 1,2, 3, 4, and 5; it will expire from period 6 onwards.
6. For products with a maturation time specified, they need to have at least 1 inventory policy with Stocking Site = True set up, either at the facility they are produced at or at a down-stream location it can be moved to (appropriate transportation policies need to be in place), so they can stay in stock until they are mature (or longer, shelf life allowing).
7. Products with a shelf life also need to have at least 1 inventory policy with Stocking Site = True set up if the product is allowed to be consumed later than the period it has been produced in (from production until before its expiry).
8. Product that can stay in inventory after expiry (Disposal Behavior = EndOfHorizon), can stay in inventory at the location it expired at if there is an inventory policy with Stocking Site =True set up for the product at this facility. It could also be moved elsewhere, if optimal to do so and the correct model structure is in place. This model structure would need to consist of:
   
   1. Transportation policies from this location to other facilities.
   2. Inventory policies with Stocking Site = True at the destination facility/facilities if the expired product is to stay there.
9. If Bills of Materials are used in the modelling and components have shelf life and / or maturation time set, these need to be respected before being used in the BOM: a component cannot be consumed by a BOM before it is mature, and it also cannot be used by a BOM after it has expired.
10. Customers often require that there is a certain minimum period of shelf life left on a product when it is delivered to them. For example, say that a specific beverage has a shelf life of 6 months, and the customer requires that when this beverage is delivered to them it still has at least 4 months of shelf life left. In this case, the shelf life to be entered into the model should be 6 – 4 = 2 months, to ensure that the product is used to fulfill the customer’s demand no longer than 2 months after it is produced.

Demo Model – Inputs

We will now showcase the use of both Shelf Life and Maturation Time in a small demo model. This model can be copied to your own Optilogic account from the Resource Library (see also the “How to use the Resource Library” Help Center article). This model has 3 locations which are shown on the map below:

1. A manufacturing facility, Plant_1, in Saltillo, Mexico. The 2 finished goods and 1 component included in the model are produced here.
2. A distribution center, DC_1, in Detroit, MI,USA. The plant ships the finished goods to this DC.
3. One customer, located in Erie, PA, USA. The customer has demand for both finished goods.

It is a multi-period model with 6 periods, which are each 1 week long (the Model End Date is set to February 12, 2025, on the Model Settings input table, not shown):

There are 3 products included the model: 2 finished goods, Product_1 and Product_2, and 1 raw material, named Component. The component is used in a bill of materials to produce Product_1, as we will see in the screenshots after this one.

1. Each product has a unit value set for inventory holding calculation purposes (= # units in inventory * product unit value * carrying cost percentage * period length / 365 days).
2. Both the Component and Product_1 have Shelf Life and Maturation Time set, and the values are all set as 3 weeks. Since Shelf Life = Maturation Time for both, it means that both need to be consumed when their age is 3: it cannot be sooner since they are not mature then, and it cannot be later as they will have expired.
   
   1. WK in the UOM fields is the symbol used for the unit of measure with Type = Time to indicate a week. See the Units of Measure input table for other units of measure of Type = Time and their Symbols.
3. For Product_2:
   
   1. Shelf Life = 27 days. Since it is a model with weekly periods, this means that the shelf life equates to 4 periods (rounding of 27 / 7 = 3.86 to the nearest integer).
   2. Maturation Time = 13 days, which equals 2 periods (rounding of 13 / 7 = 1.86 to the nearest integer).
   3. If Product_2 is for example produced in period #3, it will be mature in period #4, and it can be consumed in periods 4, 5, 6, and 7. It will be expired from period 8 onwards.

As mentioned above, a bill of materials is used to produce finished good Product_1:

This bill of materials is named BOM_1 and it specifies that 10 units of the product named Component are used as an input (product type = Component) of this bill of materials. Note that the bill of materials does not indicate the end product that is produced with it. This is specified by associating production policies with a BOM. To learn more about detailed production modelling using the Neo engine, please see this Help Center article.

In the next screenshot of the production policies table, we see that the plant can produce all 3 products, and that for the production of Product_1, the bill of materials shown in the previous screenshot, BOM_1, is used. The cost per unit is set to 1 here for each product:

For purposes of showing how Shelf Life and Maturation Time work, we will use the Production Policies Multi-Time Period input table too. In here we override the production cost per unit that we just saw in the above screenshot to become increasingly expensive in later periods for all products, adding $1 per unit for each next period. So, to produce a unit of Product_1 in Period_1 costs $1, in Period_2 it costs $2, in Period_3 $3, etc. Same for Component and Product_2:

The production cost is increased here to encourage the model to produce product as early as possible, so that it incurs the lowest possible production cost. It will also still need to respect the shelf life and maturation time requirements. Note that this is also weighed against the increased inventory holding costs for producing earlier than possibly needed, as product will sit in inventory longer if produced earlier. So, the cost differential for production in different periods needs to be sufficiently big as compared to the increased inventory holding cost to see this behavior. We will explore this more through the scenarios that are run in this demo model.

Since products will be spending some time in inventory, we need to have at least 1 inventory policy per product with Stocking Site = True. At the plant, all 3 products can be held in inventory, and there is an initial inventory of 750 units of the Component. At the DC, both finished goods can be held in inventory. The carrying cost percentage to calculate the inventory holding costs is set to 10% for all policies:

Lastly, we will show the demand that has been entered into the Customer Demand table. The customer demands 1,000 units each of the finished goods in period #6:

Other input tables that have populated records which have not been shown in a screenshot above are: Customers, Facilities, and Transportation Policies. The latter specifies that the plant can ship both finished goods to the DC, and the DC can ship both to the customer. The cost of transportation is set to 0.01 per unit per mile on both lanes.

The 3 costs that are modelled are therefore:

1. Production cost – Unit Cost field on the Production Policies Multi-Time Period table.
2. Transportation cost – Unit Cost field on the Transportation Policies table.
3. Inventory Holding cost – calculated based on the Unit Value field on the Products table and the Carrying Cost Percentage field on the Inventory Policies table.

Demo Model – Scenarios

There are 3 scenarios run in this model, see also the screenshot below:

1. Baseline – this scenario uses the inputs as they are in the input tables without any changes. See the screenshots above in the “Demo Model – Inputs” section. We will examine when the Component and Product_1 are produced so that their Shelf Life = Maturation Time = 3 weeks constraints are adhered to and explore how far in advance Product_2 is produced, weighing higher inventory carrying cost versus lower production cost when producing early.
2. Increased Shelf Life – in this scenario we make one change as compared to the Baseline: increase the Shelf Life of Product_2 to 34 days (from 30 days), which means it goes from 4 weeks to 5 weeks. The results will tell us if it is indeed beneficial to produce even earlier (lower production cost) as compared to the Baseline now that Product_2 can be available for consumption 1 period longer than before.
3. Product Value Doubled – this scenario also has 1 change as compared to the Baseline: the product value of all products is doubled. Now producing Product_2 as far in advance as possible will be less desirable as the inventory carrying cost will be double as compared to before, which may not outweigh the lower production cost in earlier periods anymore.

The screenshot shows the 3 scenarios on the left, where we see that the Increased Shelf Life and Product Value Doubled scenarios both contain 1 scenario item, whereas the Baseline does not contain any. On the right-hand side, the scenario item of the Increased Shelf Life scenario is shown where we can see that the Shelf Life value of Product_2 is set to 34. See the following Help Center articles for more details on Scenario building and syntax:

• Getting Started with Scenarios, this also contains a video on how to create scenarios
• Creating Scenarios in Cosmic Frog
• Writing Scenario Syntax

Demo Model – Outputs

Two notes upfront about the outputs before we dive into details as follows:

1. Since the transportation lanes and their costs are fixed, and we keep demand the same across the 3 scenarios, transportation costs play no factor in the optimization of  these scenarios and are the same for all 3 scenarios.
2. Both finished goods can be held in inventory at both Plant_1 and DC_1. Since this would incur the same cost (same product unit value and carrying cost percentage), we can see that sometimes a product is held in inventory at the plant whereas at other times it is held at the DC, these are equivalent solutions as the costs are the same.

Now let us first look at when which product is produced through the Optimization Production Summary output table:

1. Looking at the Component and Product_1 (remember 10 units of Component are used to make 1 unit of Product_1), we see that in all 3 scenarios, 10,000 units of Component are produced in Period_2 and 1,000 units of Product_1 are produced in Period_4. Since the demand for Product_1 occurs in Period_6 and the Component and Product_1 both have their shelf life and maturation time both set to 3 weeks, this is the only option for the model. Component and Product_1 both need to be 3 periods old when they are consumed: it cannot be later because they will have expired by then, and it cannot be sooner as they will not be mature yet. Working backwards:
   
   1. Needing Product_1 to be delivered to the customer in Period_6 means it needs to be produced in Period_4, so that its age is 3 in Period_6. 1,000 units are therefore produced in Period_4, using BOM_1.
   2. Because Product_1 needs to be produced in  Period_4 and the Component needs to be consumed for this production process (as specified by BOM_1 and connected to Product_1 in the Production Policies table), the Component needs to be 3 periods old in Period_4. Therefore, it must be produced in Period_2. 10,000 units are produced, since 1,000 units of Product_1 are demanded and 10 units of Component are used to produce 1 unit of Product_1.
2. For Product_2, we see that it is produced indifferent periods for all 3 scenarios:
   
   1. Baseline – produced in Period_3. Since Product_2’s maturation time is 2 weeks and it is demanded in Period_6, it can be produced in Period_5 at the latest. As its shelf life is 4 weeks, it can be produced in Period_3 at the earliest; its age will be 4 in Period_6 in that case. The model chooses to produce the product in Period_3 indicating that the lower production cost of producing earlier outweighs the increased inventory holding cost for holding the product in stock for longer than strictly needed based on shelf life and maturation time. As also noted above, the transportation costs are always the same in this demo model, so they do not figure into this equation.
   2. Increased Shelf Life – produced in Period_2. Product_2’s shelf life was increased from 4 to 5 weeks in this scenario and as a result the earliest it can be produced is now Period_2. The model does choose to produce it in Period_2, so again the lower production cost (from $3,000 to$2,000) outweighs the increase in inventory holding costs for holding 1,000 units of Product_2 in stock for 1 week longer.
   3. Product Value Doubled – produced in Period_5. Based on the shelf life (4 weeks) and maturation time (2 weeks), same as in the Baseline, Product_2 could have been produced in periods 3, 4, or 5. The model now chooses to produce it as late as possible, adding $2,000 to the production costs as compared to the Baseline. Because the doubled product value doubles the inventory holding costs for Product_2, the increase in production costs due to producing it later must be less than the increase in inventory holding costs would have been had Product_2 still been produced in Period_3, which we will see in the next screenshot.

The next screenshot shows the Optimization Inventory Summary filtered for Product_2. Since we know it is produced in different periods for each of the 3 scenarios and that the demand occurs in Period_6, we expect to see the product sitting in inventory for a different number of periods in the different scenarios:

1. In the Baseline, Product_2 is produced in Period_3, so the prebuild inventory in that period increases from 0 to 1,000. Therefore, the average prebuild inventory is calculated as (0 + 1,000) / 2 =500 for Period_3 (not shown in the screenshot). The prebuild holding cost for Period_3 is then calculated as follows: 500 units * 10% carrying cost percentage* $300 product unit value * 7 days (period length) / 365 days = $287.67. Since the product stays in inventory until it is sold in Period_6, the average prebuild inventory in periods 4 and 5 is 1,000 and the prebuild holding cost is double as compared to Period_3. In Period_6 the average prebuild inventory is again 500 since the starting prebuild inventory is 1,000 and the ending prebuild inventory 0, so the prebuild holding costs in this period are the same as in Period_3.
2. In the Increased Shelf Life scenario, Product_2is produced 1 period earlier (in Period_2) as compared to the Baseline, so it sits in inventory for 1 more period. This adds $575.34 to the overall prebuild holding cost. We saw however that producing 1 period earlier reduced the production cost by $1,000, so the total cost is decreased by $425.
3. In the Product Value Doubled scenario, Product_2is produced in Period_5 and sold in Period_6, leading to prebuild holding costs for 2 periods that both have average prebuild inventory of 500 units. Since the product value is doubled, this leads to a total of 2 * $ 575.34 = $1,150.68 prebuild inventory holding cost. Comparing to the Baseline where Product_2 was produced in Period_3:
   
   1. Producing in Period_5 instead increases the production cost by $2,000 ($5,000 vs $3,000).
   2. Had Product_2 been produced in Period_3 in the Product Value Doubled scenario too, the doubled prebuild holding costs (due to the double product value) would have resulted in a total prebuild holding cost of 2 * 2 * $287.67 + 2 * 2 * $575.34 = $3,452.04, which is more than $2,000 higher than the total prebuild holding cost for producing in Period_5: $3,452.04 - $1,150.68 = $2,301.36. Therefore, producing Product_2 in Period_5 rather than in Period_3 keeps the increase in total cost as small as possible.

In the Optimization Network Summary output table, we can check the total cost by scenario and how the 3 costs modelled contribute to this total cost:

1. As mentioned before, the transportation costs are constant across all 3 scenarios: the same amount is moved from Plant_1 toDC_1 and from DC_1 to Customer_1 at the same cost.
2. The differences we see in the production costs are due to producing Product_2 in different periods in all 3 scenarios.
3. The different prebuild holding costs for all 3 scenarios are due to:
   
   • Holding Product_2 in inventory for a different number of periods.
   • The doubled product value for all products in the last scenario increasing the prebuild holding cost of all 3 products.
4. If the shelf life of Product_2 could be increased from 4 weeks to 5 weeks, this would lead to an overall reduction in costs by about $425.
5. If the product value of all products was doubled, this would lead to an increase in total costs of about $4.6k.

Next, we will take a look at the 3 new output tables, which detail the age of products that are used in production, of products that are transported, and of products that are sitting in inventory. We will start with the Optimization Production Age Summary output table:

1. This table will only contain data if BOMs are used where products that are used as inputs (components) can have different ages. In our small demo model, only the Component product is used as an input into BOM_1 to produce Product_1, so we only see records for the Component product in this table.
2. As explained above, the model had no choice for when to produce Product_1 due to the shelf life and maturation time values of Product_1 and Component it had to be during Period_4 when the age of the Component was 3 weeks.

Next, we will look at the age of Product_2 when it is shipped between locations:

1. In the Baseline scenario, Product_2 is produced as early as possible due to the lower production cost outweighing higher inventory holding costs, and therefore its age when it is shipped to the customer is the maximum shelf life of 4 weeks.
2. Similarly, in the Increased Shelf Life scenario, where Product_2 now has a shelf life of 5 weeks, it is still produced as early as possible. Again, its age is the maximum shelf life of 5 weeks when shipped to the customer to fulfill its demand in Period_6.
3. Finally, in the Product Value Doubled scenario, Product_2’s shelf life is 4 weeks (same as in the Baseline). Because the prebuild holding costs would increase more when producing the product as early as possible in Period_3 as compared to the increase in production costs when producing it as late as possible in Period_5, it is produced in Period_5. This leads to an age of 2 weeks when fulfilling the customer demand in Period_6.
4. You may notice that in the first 2 scenarios Plant_1 ships to DC_1 in the same period as the DC ships to the customer, whereas in the last scenario Plant_1 ships to DC_1 in the period prior to the DC shipping to the customer. Since the transportation costs are the same regardless of when a product is shipped between these locations, and because the inventory holding costs at Plant_1 and DC_1 are the same, Product_2 could be shipped from the plant anytime from when it was produced up until Period_6 when it needs to be used to fulfill the customer’s demand; those solutions would all lead to the same total cost and are considered equivalent solutions.

Lastly, we will look at 2 screenshots of the new Optimization Inventory Age Summary output table. This first one only looks at the ages of Product_1 and Component at Plant_1 in the Baseline scenario. The values for their inventory levels and ages are the same in the other 2 scenarios as the production of these 2 products occurs during the same periods for all 3 scenarios:

1. Remember that Plant_1 had an initial inventory of 750 units of the Component. The age of these units will be 1 during the first period of the model, 2 in Period_2, and 3 in Period_3. Since its shelf life is 3 weeks, it is expired in Period_4 and cannot be used for producing Product_1 in Period_4. It then stays in inventory as expired product for the rest of the model horizon.
2. In addition to the 750 units of Component in all periods of the model, we also see entries for Component in Period_2 and Period_3 for 10,000 units. These are the units that are produced in Period_2 to be used to produce 1,000 units of Product_1 in Period_4. Since they are produced in Period_2, their age is 1 in Period_2, and 2 in Period_3. There is no record for Period_4 as the inventory has gone down to 0 due to consuming all units in Period_4.
3. As 1,000 units of Product_1 are produced in Period_4, their age is 1 during this period, and 2 in Period_5. When their age is 3 in Period_6, they are used to fulfill demand at the customer, and therefore there is no entry in this table for them in Period_6, since the inventory has gone down to 0.

In the next screenshot, we look at the same output table, Optimization Inventory Age Summary, but now filtered for Product_2 and for all 3 scenarios:

1. As we have mentioned several times before, Product_2 is produced in different periods in the 3 scenarios but always used to fulfill demand in Period_6. We see the age increasing from 1 in the period when it is produced, and no entries for Period_6 as it is used to fulfill demand in that period.
2. In the Baseline and Increased Shelf Life scenarios, the age of Product_2 when delivered to the customer in Period_6 is at its maximum shelf life (4 in Baseline and 5 in Increased Shelf Life).
3. In contrast, in the Product Value Doubled scenario, the age of Product_2 when fulfilling demand in Period_6 is 2, which is the minimum it needs to be due to its maturation time.

For any questions on these new features, please do not hesitate to contact Optilogic support on support@optilogic.com.

‍

Overview

The Optilogic Model Context Protocol (MCP) Connector links AI Agents like Claude and ChatGPT to Ada, Optilogic’s agentic AI for supply chain modeling. Together, they give teams a faster way to make better tactical decisions within today’s supply chain — and design the supply chain they need for tomorrow. Ada works with a live digital twin of your supply chain, combining mathematical optimization, simulation, and demand modeling to answer questions across the full planning horizon, from day-to-day operational response to long-term network, transportation, inventory, and production strategy.

Once connected, the AI Agent can list the model databases in your Optilogic account, open a conversation with Ada, attach one or more databases, and relay prompts and responses back and forth — all from inside the agent. This enables AI-powered what-if analysis, demand and sourcing analysis, routing and inventory tradeoffs, tariff scenarios, and network strategy without switching tools.

In practice, Ada continues to do what she does best — reasoning over your supply chain data, running analyses, and answering modeling questions. The AI Agent adds a complementary layer on top: turning Ada’s outputs into decision-ready executive summaries, spreadsheets, slide decks, and interactive dashboards, while combining them with web research and other connected tools in a single workflow.

The connector is currently available in Claude (Anthropic), ChatGPT (OpenAI), Copilot (Microsoft), Grok (SpaceXAI), and Vibe (Mistral AI).

‍

Quick Start

1. Add the Optilogic connector to the AI Agent you are using and authenticate with your Optilogic account. When prompted for the MCP Connector URL, enter: https://mcp.optilogic.app/mcp. Direct links to set up a (custom) connector for the AI Agents that currently support the Optilogic MCP Connector are:
   1. Claude: https://claude.ai/directory/optilogic
   2. ChatGPT: https://chatgpt.com/plugins (note that Developer Mode needs to be turned on prior to connecting)
   3. Grok: https://grok.com/connectors
   4. Vibe: https://chat.mistral.ai/connections
   5. Copilot: receive link from your IT Administrator, see detailed instructions here
2. In a chat with your AI Agent, ask it to list the databases in your Optilogic account to confirm the connection.
3. Tell the agent which database(s) (Cosmic Frog models, DataStar projects, or other Postgres databases) you want to work with, by name. If you are unsure, just state your question and the agent can help you identify which database(s) will help answer.
4. Ask your question or describe your task in plain language. The agent will start an Ada session, attach the right database(s), and relay your prompt.
5. Review Ada's answer, ask follow-up questions, and — when you are ready — ask to turn the findings into a document, spreadsheet, deck, or living dashboard.
6. Revisit or continue conversations anytime, plus you can see (and continue) these interactions with Ada and any work done by Ada on the Optilogic platform.

Detailed step-by-step instructions for Claude, ChatGPT, and Copilot, including screenshots, can be found here:

• Getting Started with the Optilogic MCP Connector in Claude
• Getting Started with the Optilogic MCP Connector in ChatGPT
• Getting Started with the Optilogic MCP Connector in Copilot

Understanding the Optilogic MCP Connector

What Is It?

The Optilogic MCP Connector is a Custom Connector for AI Agents built on the Model Context Protocol (MCP). It gives AI Agents a set of tools that let it act as an orchestrator for Ada conversations: discovering your models, starting and managing Ada sessions, attaching databases, and polling for Ada's (asynchronous) responses.

It is not a replacement for Ada or for the Optilogic platform — it is a bridge. Ada still does the actual modeling work; the connector simply gives the agent a way to ask it questions and receive answers.

A useful mental model: the AI Agent is the orchestrator and communicator; Ada is the subject-matter expert on your models.

What Should I Use It For?

Teams are using the Optilogic MCP Connector for tasks like:

• Interrogating scenario outputs — cost drivers, service-level trade-offs, which facilities open or close
• Comparing multiple models or scenarios side by side
• Sanity-checking model data for missing values, outliers, or duplicates before a solve
• Turning Ada's analysis into executive summaries, board-ready briefs, and slide decks
• Building scenario-comparison workbooks and interactive dashboards from model outputs
• Filling gaps in a model with outside context — for example, pulling real-world wage or tariff data to round out a scenario

The Connector works best for grounded, model-based questions where Ada supplies the underlying facts and the agent handles synthesis, formatting, and communication. It is less suited to open-ended business strategy discussions that have no connection to an actual model or dataset - “What happens to warehouse utilization if demand is up 5% across category A?” is only meaningful when asked in the context of a model.

What the Optilogic MCP Connector Can and Cannot Do

*To learn more about using Optilogic Teams, please see this Getting Started with Optilogic Teams Help Center article.

**To learn more about Ada’s interaction style and agent options, please see the Create Your First Prompt section in the Getting Started with Ada & Agentic AI Help Center article.

Prior to Setting Up

Before you set up and start working with the Optilogic MCP connector, please take note of following:

• To use the connector, you need to have an Optilogic user account and a user account on the AI Agent you want to use the connector in.  
  • You can create an Optilogic account on the Create a Free Account page (step-by-step instructions are here)
• The AI Agents are third-party services governed by your terms with the AI Agent’s company.
  • See for example Anthropic’s consumer and commercial terms of use.

Tools and Descriptions

The following tools are available to the connector:

Agent Lifecycle

Past Conversations

Artifacts

Workspace Files

‍

Sharing

Account / Teams

Data

‍

Example Prompts by Use Case

The prompts below are starting points — swap in your own model names, regions, priorities, etc.

Getting Oriented

• Inventory your models: “Using the Ada connector, list all the models in my Optilogic account and group them by what they appear to be for (production models, tests, training exercises).”
• Profile a model before diving in: “Start an Ada session with my ‘[MODEL NAME]’ model attached. Ask her to summarize the model: what tables it has, how many customers/facilities/products, what scenarios exist, and whether there are solved outputs.”

Analysis & Insights

• Interrogate scenario outputs: “Ask Ada (with ‘[MODEL NAME]’ attached): which scenario has the lowest total cost, what drives the difference vs. baseline, and which facilities open or close in each scenario? Then summarize her answer as a comparison table.”
• Compare across models: “Start an Ada session with both ‘[MODEL A]’ and ‘[MODEL B]’ attached. Ask her how the two models differ in network structure, demand, and assumptions, and which is more current.”
• Sanity-check model data: “Ask Ada to profile the data in ‘[MODEL NAME]’: missing values, orphaned records, duplicate names, suspicious outliers in demand or costs. Have her rank issues by severity, then give me a cleanup checklist.”

Deliverables — Where AI Agents Shine

• Executive summary from model outputs: “Ask Ada about the scenario results in ‘[MODEL NAME]’ (costs, service levels, key network changes). Then write a 1-page executive summary as a Word doc for leadership — plain language, decision-focused.”
• Scenario comparison workbook: “Get scenario-by-scenario cost and flow summaries from Ada for ‘[MODEL NAME]’, then build an Excel workbook: one tab per scenario, plus a comparison tab with deltas vs. baseline and a chart.”
• Results readout deck: “Interview Ada about ‘[MODEL NAME]’ — objectives, scenarios tested, key results, recommendation. Then build a 5-slide PowerPoint readout: context, approach, results, tradeoffs, recommendation.”

Broader Supply-Chain Scenarios to Try

• Network redesign trade-offs — build several distribution network scenarios and summarize cost, service-level, and risk trade-offs for the board
• Cost-to-serve diagnosis — run a cost-to-serve analysis by segment/channel and flag unprofitable segments
• Disruption stress test — simulate a supplier or port disruption and write an executive risk memo
• Greenfield site selection — weigh candidate sites against strategic priorities and draft a siting recommendation
• Reshoring / nearshoring business case — model a production shift and produce a cost-benefit summary
• Tariff shock scenario — re-run sourcing with a tariff increase and quantify the cost impact
• Demand shift scenario — model a demand shift and recommend how to rebalance the network

‍

Best Practices

• Name the Model Explicitly: Ada only sees databases attached to the conversation. Telling the agent the exact model name(s) ensures the right one(s) get attached the first time. If you are unsure of which database to use, ask the agent and you can pick from a list.
• Chain, Do Not Cram: Ask Ada focused questions in sequence rather than one giant prompt. Because sessions keep context, follow-up questions are cheap — you do not need to restate everything each time.
• Let Each Side Do Its Job: Use Ada for anything touching model data, and the agent for formatting, synthesis, web research, and file creation. Trying to get the agent to reason about model internals directly, without Ada, will produce weaker answers.
• Capture the Raw and the Polished: Before you ask the agent to build a polished deliverable, ask it to show you Ada's raw answer first. This makes it easy to catch a misreading early, before it propagates into a document or deck.
• Multi-Attach for Comparisons: When you need cross-model answers, one Ada session with two databases attached beats juggling two separate sessions.
• Give Context Before the Task: As with Ada directly, better prompts include business context, constraints, and the specific task — not just the task alone.
• Start Fresh for a New Topic: If you are switching to an unrelated model or question, start a new conversation rather than overloading one thread.
• Ask for Multiple Options: Instead of one recommendation, ask Ada (via the agent) for several approaches and their trade-offs.
• Supplement Missing Data: If Ada flags gaps in the model, ask the agent to search the web for relevant proxy data to round out the story — and to cite where it came from.

‍

Data Handling and Privacy

When you use the Optilogic MCP Connector, prompts and the data Ada returns pass through the agent in order to be displayed, summarized, or turned into a deliverable. This is in addition to — not a replacement for — Optilogic's own data handling for Ada itself.

• Data users share with the AI Agent is governed by the AI Agent company’s privacy policy; Optilogic's privacy policy applies once data reaches Ada on the Optilogic platform.
  • AI Agent privacy policy example: Anthropic (Claude) Privacy Policy
  • Optilogic Privacy Policy
• Optilogic’s data policies can be found here: Optilogic Trust Center; Optilogic’s specific data policies for AI can be found here: AI Data Security and Privacy.
• As with any connector, only attach the database(s) you intend to discuss in a given conversation.
• Avoid including sensitive information (PII, credentials, etc.) in prompts, table names, or column names, since these may be passed to the underlying AI systems on both sides of the connection.

What the MCP Server Collects and How it is Used

The MCP Server connects AI agents to Optilogic's Public APIs and Ada, Optilogic’s native AI agent. Ada and the Public APIs have logging in place; MCP server calls are logged in accordance with those practices with additional meta data to identify it as coming from the MCP, nothing additional - it does not have any user identifiers in it.

The MCP Server only processes the tool-call payloads needed to fulfill the requests; surrounding conversation context from the agent is not retained. In addition to serving the request, tool-call data is also used for the following purposes:

• Debugging: MCP request/response data and associated logs may be reviewed to investigate errors and user-reported quality issues.
• Analytics: Optilogic collects usage data (such as prompt counts, session activity, token consumption, timestamps) associated with the user account to understand adoption and improve the service.

For clarity, Optilogic does not use logs for model training.

Data Retention

MCP request/response data and associated logs are stored in accordance with Optilogic's Data Retention Policy. You can learn more here -- How We Safeguard Your Data: Backups & Retention Explained.

What happens when Disconnecting the Connector

Disconnecting the Connector on the AI Agent’s settings tells the agent to stop using and refreshing your Optilogic tokens — that is the immediate effect.

After disconnecting, the historical chats that were had through the connector are still accessible to the user, just no follow-up prompts that require accessing Ada can be added.

Visibility on the Optilogic Platform

Please note that users have visibility into the MCP Connector conversations and actions on the Optilogic platform in following places:

• Users can view the calls made by the MCP Server to Ada in their Optilogic account Chat history; they are tagged as MCP.
• Users can view model run activity from the MCP in their Optilogic account as a part of their broader account usage under the Account > Usage screen.

Troubleshooting

If the conversation with Ada through the AI Agent seems to go off track, e.g., gives no response or odd/incorrect responses, please follow these troubleshooting steps:

1. Ensure you are logged into the correct Optilogic account (in case you have multiple Optilogic accounts) and are working in the correct workspace (My Account vs a Team account). You can test this by asking the agent which Optilogic account and which workspace it is logged into. If logged into the wrong Optilogic account, go to bullet #5; if working within the wrong workspace, ask the agent to switch to the correct workspace. If not resolved, then:
2. Double-check the data you are trying to access exists in the logged in account and workspace on the Optilogic platform itself. If not resolved, then:
3. Start a new conversation – this is always recommended when switching between Optilogic accounts / workspaces / databases / major tasks. If not resolved, then:
4. Do a hard refresh of your browser (Ctrl +Shift + R on Windows, Cmd + Shift + R on Mac) / restart your desktop application – this may be needed when a newer version of the connector becomes available. If not resolved, then:
5. Disconnect and reconnect the Optilogic MCP Connector.
   1. Note that this is required when switching between Optilogic accounts.
6. If you are still having trouble, please contact the Optilogic support team on support@optilogic.com.

Example Conversation Walk-through

Example Overview

In this example, we will:

1. Connect to a Hopper model named Territory Planning
   1. This model can be copied to your account from the Resource Library: Territory Planning model on the Resource Library
   2. The model is documented in this Territory Planning (Transportation Optimization) Help Center article
   3. We made 1 change: removed the Distance Cost of $1/MI in the Transportation Rates table
2. Inventory what is in the model in terms of inputs and scenarios
3. Identify any missing data and potentially useful scenarios to add
4. Fill the data gap using publicly available sources
5. Add several scenarios based on the recommendation
6. Run all scenarios
7. Generate a summary of the outputs, including an interactive map showing the routes by scenario

Claude was used in this example; using the same prompts in another AI Agent will result in similar responses.

Summary of Prompts and Responses

The prompts used and a summary of the responses follows here, see the appendix for the full conversation captured in screenshots. Note that the some of the “Please check” prompts to check back in with Claude if there is a response from Ada yet when Claude has stopped polling are omitted here.

Prompt 1: Using the Optilogic Ada connector, can you review the inputs of the Territory Planning model? Please give me a summary and also check which costs are being modeled.

Response:

• High-level description of the type of model and its scenarios
• Summary of the model inputs, including row counts and notes on the data in the tables
• Overview of costs populated and those available but not populated
  • The only cost used is fixed cost per route, and no variable transportation cost is included
• Summary of findings

Prompt 2: Can you find what the average per mile cost for trucks in the Atlanta region is and add this to the model?

Response:

• Found national spot dry van rates at about $2.30-2.70/mile
• Atlanta region runs above national average at about $3.20/mile
• Flags that these are long-haul, full-truckload linehaul rates, whereas the model is a local delivery/routing model where cost drivers are different and a per mile cost is harder to find
• Suggests 2 reasonable choices for Distance Cost. The user chooses $3.20/mile, the Southeast regional spot freight rate.

Prompt 3: Before re-running, can you suggest a top 3 of additional scenarios that would be interesting to run, based on the expected value / insights they may provide?

Response: lists 3 sets of suggested scenarios to add and the reasoning:

• Time cost + stop cost added, re-run across territory counts
• Territory count sensitivity – sweep beyond 3 and 5
• Truck capacity/fleet size stress test

Prompt 4: Please add the scenarios for your #2 suggestion, territory count sensitivity, then run all scenarios (Hopper). Once done running, please create the trade-off curve for number of territories vs cost and an interactive map where the multi-stop routes of each scenario can be visualized, including tooltips and main KPIs by scenario.

Response:

• After some time working on the request, the user is asked to confirm the logic for the minimum delivery locations per territory for the new scenarios and the scenario naming. The user approves.
• The result is a downloadable interactive html file which contains Route Map and Cost Curve tabs. Users can switch between the scenarios and hover over the map / chart to bring up a tooltip with information about the route / scenario.

Other Helpful Resources

• Getting Started with the Optilogic MCP Connector in Claude
• Getting Started with the Optilogic MCP Connector in ChatGPT
• Getting Started with the Optilogic MCP Connector in Copilot
• Getting Started with Ada & Agentic AI
• Understanding Ada Credits
• Modeler AI Agent

Questions or feedback on the connector? Reach out to the Optilogic Support team on support@optilogic.com. In addition, you can use the thumbs-up and thumbs-down buttons in the AI Agent chat to send feedback directly to the AI Agent’s company on any specific response.

Appendix – Example Conversation Screenshots

This documentation details how to connect and disconnect the Optilogic MCP connector using Copilot. To learn more about the Optilogic MCP Connector, please see The Optilogic MCP Connector Help Center article. It includes an explanation of what the connector is, how it can be used, example prompts, best practices, data handling and security details, and troubleshooting pointers.

Summary of Steps

The steps to take when connecting to the Optilogic MCP Connector in Copilot are as follows:

1. An IT administrator within your company creates a new agent connecting to the Optilogic MCP connector on the company’s Copilot account.
2. The administrator shares the link to the new agent with company employees who wish to connect to the Optilogic MCP Connector.
3. Individuals connect to the agent using the link from their IT administrator.

These steps are covered in detail in the next sections.

Creating an MCP Agent (IT Administator)

The following steps to create an MCP agent need to be completed by an IT administrator.

1. Create a New Agent

Navigate to Copilot Studio (https://copilotstudio.microsoft.com/), and Open the Agents page. Then, choose New Agent:

Provide a name for your agent, for example, Optilogic MCP.

2. Configure the Agent

Choose a model to leverage from the drop-down list. As of August 2026, GPT 5.6 Reasoning works well; other models may work fine too. Once you have chosen your model, open the Tools menu by clicking on the plus button to the right:

In the Tools menu, click on the Add button, then select Model Context Protocol (MCP):

In the Add MCP server form that comes up, enter the following:

• Server name: Optilogic
• Server description: Optilogic MCP Connector
• Server URL: https://mcp.optilogic.app/mcp‍
• Authentication: OAuth 2.0

Once added, provide some basic instructions for the agent such as “You are an agent designed to assist with Ada in the Optilogic platform.”.

‍

3. Publish the Agent

Save and publish the agent. The Save button is just left of the publish button; next, click on Publish. Upon publishing a window will pop up with final settings. Be sure to check the box to make the agent available in Microsoft 365 Copilot:

Still on the same form, click on the Availability options button, scroll to the bottom of the menu, and click on the Share Agent button to choose which users can access the agent. Alternatively, you can select the Share Agent button and enable end-user access for all users in the organization:

4. Associate a Billing Profile

Finally, you will need to associate a Microsoft Power Platform billing profile to agents created in Copilot Studio for the agent to function. Copilot agents require credits separate from end-user Copilot licensing. To explore current offerings from Microsoft and manage billing profiles, please see this webpage.

Individual Connection Instructions

1. Open the Connector Link

Once IT creates the agent on your company’s Copilot account, they can share a link with you to the new agent, which will look similar to the next screenshot. Click on the Open button.

The agent will be added to your Copilot account to chat with – notice it under Agents in the left pane:

2. Connect to the Agent

Start a chat with the agent and prompt it to connect to your Optilogic account. When you see the card for Connection Required, click on Set up connection:

A browser window will open. Click on Connect under Actions:

In the Connection drop-down list, select Create new connection:

Enter a display name and click on Create:

3. Sign in to Optilogic

When prompted, sign in to your Optilogic account:

The connection is complete! You will see the checkmark for confirmation:

4. Test the Connection

Go back to your Copilot chat window and test it out with a first prompt, such as: I just connected Optilogic. Give me a summary of what you can do with Optilogic, what you see in my Optilogic account and highlight one useful insight that you recommend I dig in to. Also, what sort of “what if” questions can you answer based on what you see in my account?.

Ada Credits are used to access Ada and other AI-powered capabilities in the Optilogic platform. Credits are provisioned as a shared pool at the organization level, so eligible users draw from the same balance.

This article explains how Ada Credits work, where to see your organization’s usage, what happens as credits are consumed, and what to do when an organization’s credits are exhausted.

Quick Answers

How Ada Credits relate to Tokens

Ada uses large language models (LLMs) to process requests and generate responses. LLMs use tokens as part of that process. Tokens and Ada Credits are related, but they are not the same:

• Tokens are what the underlying LLM uses to process information and generate responses.
• Ada Credits are an Optilogic-specific measure used to account for Ada usage.
• Token usage is one component of the overall calculation used to determine Ada Credit consumption.
• Ada Credits are therefore not a one-to-one representation of tokens used by the LLM.

MCP Connectors and Ada Credits Usage

When an AI Agent such as Claude or ChatGPT uses the Optilogic MCP Connector to interact with Ada as part of completing a task, the work performed through that interaction contributes to Ada Credit usage.

MCP Connector usage can therefore consume Ada Credits. This is separate from the AI Agent’s own token usage.

How Ada Credits are Provisioned

Ada Credits are provisioned as a shared pool for your organization rather than as individual allocations for each user or team.

• All eligible users in your organization draw from the same pool.
• When you use Ada, your usage comes from the organization’s available credits.
• You do not have a separate personal allocation of Ada Credits.
• Your organization’s credit balance and usage are visible to all organization members.

If your organization is a paying Optilogic customer, it receives a one-time credits allotment, free of cost. Once credits are used up, more can be purchased, see below how.

Viewing Ada Credits Usage

You can view your organization’s Ada Credit balance from your profile settings.

1. Open Profile settings from your account in the lower-left corner of the Next Generation Optilogic Platform.
2. Click on Usage.
3. At the top of the page, locate the Shared Ada Credits section.
4. Review the credits available to your organization and how much has been consumed.

Because Ada Credits are shared at the organization level, the usage shown represents organization-wide usage, not just your individual usage.

Usage Notifications

Ada displays notifications directly in the Ada chat interface as your organization approaches its credit limit.

You will see warning banners when your organization reaches 75%, 85%, 95%, and 100% of its available credits. The banners change as usage increases so that you know when your organization is approaching its limit.

When Credits are Exhausted

Once your organization’s Ada Credits are exhausted, you can no longer use Ada. The Ada chat interface displays a notification indicating that the organization’s credits have been used and provides a Contact Support option.

The following features are affected when Ada Credits are exhausted:

• Ada is no longer available for chat.
• AI Agents using the Optilogic MCP Connector can no longer chat with Ada.
• DataStar Run AI Agent tasks cannot be run anymore.

Leapfrog is not affected by Ada Credit exhaustion. Users can continue to use Leapfrog within DataStar and Cosmic Frog.

Getting additional Ada Credits

If your organization needs additional Ada Credits, use the Contact Support link shown in the banner saying 100% of credits have been used, see the first screenshot in the previous section.

Support will review and route the request as appropriate. If additional credits are purchased, the organization’s credit pool is updated by Optilogic, and the new balance becomes available on the platform.

Additional credits cannot currently be purchased or added directly within the platform.

Other Helpful Resources

• Getting Started with Ada & Agentic AI — introduction to Ada and instructions for getting started.
• The Optilogic MCP Connector — learn how to combine the strengths of Ada and AI Agents.
• Next Generation Optilogic Platform Overview — learn more about the new Optilogic platform.
• Navigating Cosmic Frog – all the ins and outs of Optilogic’s cloud-native, AI-first supply chain design platform.
• Navigating DataStar – learn more about Optilogic’s AI-powered data product.

Overview

Ada is Optilogic’s next-generation agentic AI, enabling supply chain teams to work faster and with greater confidence across the full modeling lifecycle — from raw data preparation to optimization runs to executive reporting — all through natural language interactions.

Unlike traditional UI chat assistants, it deploys purpose-built agents that can pursue multi-step goals, use specialized skills, maintain conversational context, and coordinate with each other to complete workflows that previously required significant manual effort. This dramatically reduces the time required to move from raw data to recommendations.

As a core part of Optilogic’s Next Generation User InterfacePlatform, Ada provides a more intelligent and conversational approach to supply chain design work.

Ada is named after Ada Lovelace, widely regarded as the world’s first computer programmer and one of the earliest visionaries to recognize the potential of computational systems beyond pure calculation. The name reflects Optilogic’s goal of building intelligent systems that help people solve complex problems through collaboration between human expertise and advanced computing.

Quick Start

1. Log into the Next Generation UI Optilogic platform at https://ai.optilogic.app or click on the Ada icon in the navigation bar on the current Optilogic platform at https://optilogic.app
2. Ask Ada your question or to perform a task through chat in the top central part of the platform:
   1. Choose which database(s) the prompt applies to
   2. Choose which AI Agent to use
   3. Type your prompt in the chat textbox and click on submit, or
   4. Click on an example prompt
3. Respond to any clarifications Ada needs
4. Authorize any actions if needed
5. Review responses & results

Understanding Ada

What is Ada?

Ada is your AI-first supply chain modeling partner, designed specifically for the Optilogic platform. Through a conversational interface, Ada helps users build, validate, analyze, and improve supply chain models.

You can think of Ada as a chat agent like for example Claude and ChatGPT. But, unlike general-purpose AI chat tools, Ada is trained around supply chain modelling workflows and has access to Optilogic-specific tools, applications, databases, schemas, and platform capabilities.

Today, Ada includes three specialized AI Agents:

• Modeler Agent - a supply-chain modeling assistant focused on turning data into optimization-ready ANURA datasets and running/diagnosing solves (NEO / Hopper) in a disciplined, schema-driven way.
• Data Cleanser Agent - A data quality and transformation agent that can profile datasets, identify issues, standardize data, apply transformations, and validate results.
• Next Gen UI Agent – an interface-focused agent that helps users explore data, monitor work, and take action inside the Optilogic Next Gen UI platform.

‍

The Select the AI Agent part of the Create Your First Prompt section further below includes guidance on which agent to use for what type of question/task.

For a deeper technical explanation of how AI agents, tools, and skills work together, see the AI Agents: Architecture and Components help center article.

What Should I Use Ada for?

Teams commonly use Ada for:

• building optimization-ready datasets
• validating model structure and assumptions
• profiling and cleaning raw supply chain data
• generating scenarios for comparison
• interpreting optimization outputs
• summarizing findings for stakeholders
• identifying modeling gaps before solver runs
• exploring unfamiliar models or databases
• creating repeatable data cleansing and model building workflows
• analyzing and summarizing existing workflows

Ada works best for:

• multi-step analytical workflows
• iterative model refinement
• exploratory analysis
• structured operational tasks

Ada is less suited for:

• highly ambiguous business strategy discussions with no data/model context
• production-critical actions without human review
• tasks requiring unsupported integrations or external internet access

How to Think About Ada

Ada is best thought of as:

• a collaborative modeling partner
• capable of reasoning across multiple steps
• able to interact with connected Optilogic tools and databases
• but still dependent on the quality of the instructions and context provided

Ada does not automatically understand:

• your business goals
• model intent
• undocumented assumptions
• organizational conventions

The clearer the context you provide, the better the results typically become.

What Ada Can Connect to

Ada can connect to:

• Cosmic Frog model databases — Postgres databases with a standard Anura schema that optimization and simulation engines read from and write to. The Modeler Agent builds and validates models here and can query them to perform various types of analysis.
• DataStar project databases — Postgres databases with a Starburst schema used by DataStar, the Optilogic platform application for data transformation work. The Modeler Agent can interact with DataStar macros and tasks for data workflows. Both the Modeler Agent and the Data Cleanser Agent can read from and write to DataStar Project Sandboxes.‍
• Postgres databases — any other Postgres databases on the Optilogic platform. The Data Cleanser Agent and the Modeler Agent can work with these alongside Cosmic Frog models and DataStar Project Sandboxes. ‍
• Optilogic optimization engines — the Modeler Agent can launch NEO (network design and optimization) and Hopper (multi-stop transportation routing) solver runs directly. ‍
• Optilogic platform storage — both the Modeler Agent and Data Cleanser Agent can create artifacts that can be saved in the user’s Optilogic account (accessible through the Explorer application). These artifacts include for example Python scripts (.py files), markdown documents (.md), and web browser files (.html).
  

Ada operates entirely within the Optilogic platform and your connected databases. It does not access the internet or any data or systems outside of the Optilogic environment. It does not send your data to third parties beyond what is required by the underlying GPT family model API (see AI Data Security & Privacy).

What to Expect When Working with Ada

Ada may:

• ask clarifying questions
• propose plans before execution
• require approvals before modifying data
• occasionally provide imperfect or incomplete answers
• improve when given more structured context

How to Use Ada

‍

To start using Ada, log into the next generation Optilogic platform at https://ai.optilogic.app or navigate there by clicking on the Ada icon in the navigation sidebar while on the current Optilogic platform (https://optilogic.app):

Besides this documentation, you can also get a guided tour on how to use Ada from within the platform itself. In the sidebar on the left, click on the Apps Launcher icon:

Then search for “Start Ada chat” and click on the Start Ada Chat Walkthrough item in the Actions list to start the tour:

How to Access Ada

When logged into the next-gen platform at https://ai.optilogic.app, there are 2 main ways to start using Ada:

1. Go to the Home page, if not yet there, by clicking on the icon in the sidebar along the left of the platform.
2. Ada will be available through chat at the top in the central part of the platform. Note other widgets are available below Ada.
3. If you want to just chat with Ada without other widgets and/or access historical conversations, click on the chat bubble icon in the sidebar. The whole central part of the platform will then be used by your chat with Ada:

Create Your First Prompt

In a new conversation, you first need to configure chat style (optional), select your database(s), choose your agent, and then enter your question/task for Ada.

Note that for any further questions within the same conversation, the chat style, database(s), and agent do not need to be configured again – they will remain as they were set for the first prompt.

Set Interaction Style

1. To choose the style for your conversations with Ada, click on the settings icon at the left bottom of the prompt textbox.
2. Click on the Style drop-down list to view the options. The selected style has a darker background and a checkmark. Choose from:
   1. Scout (default)
      • Low autonomy - asks before significant actions
      • Explains plans before execution
      • Best for careful, high-impact modeling work
   2. Dash
      • High autonomy - makes reasonable assumptions and proceeds
      • Minimizes confirmation pauses
      • Best for rapid iteration and experienced users
   3. Mentor
      • Medium autonomy – proceeds with reasonable assumptions for routine steps; pauses to confirm key modeling choices/trade-offs
      • Explains reasoning while working
      • Highlights trade-offs and modeling decisions
      • Best for collaborative and educational workflows
   4. Caveman
      • Medium autonomy - proceeds on defaults for routine steps; only asks when a decision materially changes outcomes or is irreversible
      • Short, terse responses with minimal commentary
      • Best for experienced users who prefer compact interactions

‍

Select Database(s)

1. Click on the Databases drop-down list to view the available databases in the account you are working in. These can be Cosmic Frog models, DataStar projects, and Postgres SQL databases.
2. You can use the search box to quickly find the database(s) of interest.
3. At the top of the list, Cosmic Frog models will be listed. Here the one named Global Supply Chain Strategy C2S has been selected.
4. Further down the list, DataStar projects are listed. Here the one named AI Agents is selected.

‍

Select the AI Agent

1. Click on the Agent drop-down to view the available agents.
2. Choose the one most suitable for your question/task.

To guide you on choosing the best agent for the task, here is an overview of what each is good at.

Modeler Agent:

• Mapping cleaned / staged data into ANURA-structured inputs for Neo and Hopper (Customers, Facilities, Products, Demand, Shipments, etc.)
• Schema / enumerate / UoM compliance checks, referential integrity for model tables
• Pre-solve viability checks (connectivity, capacity vs demand, scenario alignment)
• Running NEO / Hopper and diagnosing preprocessing / validation / empty-output issues
• Output analysis of Neo / Hopper solves, including reports comparing scenarios, summarizing KPI’s, etc.
• Analyzing, designing and creating DataStar projects and macros, for example to leave behind data transformation steps in a repeatable Macro

Data Cleanser:

• Profiling data
• Fixing missing / invalid values, duplicates, outliers
• Standardizing names / IDs (customer / product / facility crosswalks), units, date formats
• Reshaping raw extracts into clean staging tables
• Reconciling keys across sources (referential integrity checks)

Next Gen UI Agent:

• Showing live dashboards (jobs, model previews) as interactive widgets
• Querying your databases (read-only SQL) and render results as tables, KPIs, and charts
• Exploring schemas (tables / columns / relationships) so we can write correct queries
• Navigating / opening apps (SQL Editor, Cosmic Frog, Run Manager, etc.) via buttons
• Helping manage your work (projects/goals/tasks) with reviewable drafts for multi-step changes

Ada’s Response

Once a prompt has been submitted, Ada will process it and formulate a response. Responses can have different formats, here we will see a text only result, while other response types are covered in the next section.

1. The user submitted the prompt “Please profile my data”.
2. While Ada is processing the prompt, a status line appears which includes how long she has been processing the prompt for and information on the current step she is on. This section can be expanded, like it is here, by using the caret icon on the left.
3. Since the status section is expanded, we see all of Ada’s steps here.
4. These icons at the top left of the detailed status section can be used to just filter the list for Status updates, Thinking steps, Tool calls, Knowledge retrieval steps, and AI steps (left to right; latter 2 not shown here as they were not used).
5. Use these 2 icons to collapse and expand all steps in the status list.
6. If you want to stop Ada’s execution, you can click on the stop button.

Once Ada is done processing the prompt, the response will be displayed:

1. In the, now collapsed, status line we see that the response took 1.2 minutes.
2. On the right-hand side in the status line, users can click on this icon to open the list of Status Updates.
3. Clicking on this icon opens the list of Tool Calls made while processing.

The full response for this prompt is shown in the next 2 screenshots:

1. Users can copy the response text by clicking on this copy icon.
2. To help Ada continuously improve, users can give a thumbs up or down if the response is considered good or poor.
3. To continue the conversation, type your follow up question/task in the prompt textbox. Ada will remember the context of the conversation so far and will use it to respond to follow-up prompts.

Additional Response Types and Interactions

Besides responses that are purely text-based, you will come across other types too. For example, when your input is needed, Ada will pause the response and ask you for feedback:

1. As a follow-up from the previous prompt, the user has asked Ada to go ahead and clean the just profiled tables.
2. The current status indicates that Human in the Loop (HITL) feedback is required now.
3. The top part summarizes why HITL feedback is needed and states what will happen once the feedback is received.
4. Often, Ada will propose several ways forward and all the user needs to do is click on the desired option. A selected option is shown in a darker color.
5. If the user does not want to go forward with an Ada-proposed option, they can use the textbox to provide instructions on what to do for that specific feedback item. Additional context can be provided here too.
6. Once feedback options are selected, click on “Send response” for Ada to continue processing.
7. If it has become clear that the prompt will not achieve what you intended or you need more time to look into something Ada surfaced, you can click on “Stop agent” to halt execution.

When Ada modifies a Cosmic Frog model or a DataStar project sandbox, users can verify these in the respective applications on the current platform (https://optilogic.app). Here, we are checking if the data cleaning step indeed created the clean_ tables in the sandbox of the connected DataStar project:

Responses can also contain files:

1. The user has prompted Ada to create a scenario comparison report in HTML format.
2. The top part of the response summarizes what Ada has done.
3. Two files are available in the response, this first one is a Python script which a user could save for future use to create scenario comparison reports using the same logic.
4. This is the report itself. Use the 3 buttons to the right of the report name to download it, save it to your workspace, or to open it in the Lightning Editor application.
5. If a conversation has generated any artifacts, this icon with the number of artifacts will be showing. This way you can easily access all artifacts if you are further up or down in a conversation.

When saving an artifact to your workspace, the following modal will come up where you can choose the location to save it and indicate if any pre-existing files with the same name at the chosen location should be overwritten or not:

When choosing to open the report in Lightning Editor, it does so in the new platform, to the right of the conversation with Ada so users do not need to change context:

The Next Gen UI Agent can help you for example with changing the look and feel of the platform’s UI. In this example it created a tour on how to customize the UI where the user can click on the buttons in the response to be taken directly to that part of the UI. Note that only part of Ada's response is shown in the screenshot:

Historical Conversations

Conversations with Ada are by default saved and users can return to them to review, audit, or continue the conversation.

1. Click on the chat icon in the task bar to open Ada and any historical conversations.
2. To just see your current conversation, click on the close icon at the right top to close the list of historical conversations.
3. To start a new conversation, click on the plus button.
4. To quickly find a conversation, use the search box.
5. Use these buttons to refresh the list, select 1 or multiple conversations for bulk delete, or to filter the conversations list either by date or based on tags (automatically assigned).
6. A card for a conversation in the list contains:
   1. The conversation’s name, by default this is the first prompt in the conversation.
   2. When this conversation was had.
   3. How many messages there are in the conversation, this includes user prompts and Ada responses.
   4. Any tags to facilitate filtering conversations.
   5. Use this button to surface a context menu with pin, rename, and delete options for the conversation.
   6. This delete button can also be used to remove a conversation.

Best Practices

Keep Conversations Focused

Ada performs best when conversations stay centered on a single task or workflow. Avoid mixing unrelated activities — such as model building, reporting, and data cleansing — in the same chat.

Focused conversations improve response quality, reduce confusion, and make it easier for Ada to maintain context.

Give Context Before the Task

Provide business context, objectives, constraints, and relevant background before asking Ada to perform work.

Better prompts typically include:

1. Business or modeling context
2. Constraints or requirements
3. The specific task

Example: Instead of: “Build scenarios for this model.”

Try: “This model evaluates manufacturing diversification risk across LATAM and EMEA. The goal is to reduce China dependency while minimizing transportation cost increases. Create several realistic diversification scenarios.”

Ask Ada to Explore Before Acting

For complex workflows, first ask Ada to explore, profile, summarize, or analyze the environment before making changes.

Examples:

• “Explore the current model and summarize its structure and assumptions.”
• “Profile the selected datasets and identify data quality issues.”

This gives both you and Ada better shared context before execution and reduces downstream errors.

Plan First for Multi-Step Workflows

For larger workflows, ask Ada to propose a plan before executing actions.

Example: “Before making changes, provide a step-by-step plan for how you would approach this workflow.”

This allows you to:

• validate assumptions early
• review sequencing
• catch issues before execution
• maintain better control over complex tasks

Be Explicit About Constraints

Clearly state any important rules or limitations.

Examples:

• “Do not overwrite existing tables.”
• “Do not modify baseline assumptions.”
• “Only use cleansed datasets.”
• “Do not generate synthetic data.”

Explicit constraints improve consistency and reduce unintended actions.

Ask Ada Clarifying Questions

If a workflow is complex or ambiguous, invite Ada to ask clarifying questions before proceeding.

Example: “Before executing, ask any clarifying questions needed to complete this task correctly.”

This often improves first-pass accuracy significantly.

Start a New Conversation When Switching Contexts

Create a new conversation when:

• changing interaction style, database(s), or Agent
• switching between unrelated tasks
• moving from brainstorming to execution
• responses become inconsistent or degraded

Long conversations can dilute context and reduce response quality over time.

Tips & Tricks

Ask for Multiple Options

Instead of requesting a single recommendation, ask Ada for multiple approaches and trade-offs.

Example: “Provide three approaches for supplier diversification and explain the trade-offs of each.”

This helps surface alternatives and improves decision-making.

Re-State Important Constraints During Long Workflows

In long conversations, periodically remind Ada about key requirements.

Examples:

• “Reminder: do not modify schema structure.”
• “Reminder: baseline assumptions must remain unchanged.”

This helps reduce context drift.

Generate a Summary Before Starting a New Chat

If a conversation becomes long or complex, ask Ada to summarize:

• goals
• decisions
• assumptions
• constraints
• unresolved issues

You can paste this summary into a new conversation to preserve context without carrying forward unnecessary noise.

Helpful prompt: “Summarize this conversation into a clean handoff document including goals, technical decisions, constraints, and next steps.”

Avoid Overloading Prompts

More information is not always better.

Instead:

• provide only relevant context
• break large inputs into sections
• clearly label important information
• keep the most critical instructions near the top

Focused prompts generally produce better results than overly large or unstructured requests.

Ask Ada What It Can Do

If you are unsure how to approach a task, ask Ada directly.

Examples:

• “What can this agent help me with?”
• “What are best practices for this workflow?”
• “Show me example prompts for this task.”
• “Create a guided tour of this feature.”

Ada can often suggest workflows, prompts, and capabilities you may not know are available.

Current Limitations and Known Behaviors

Ada is evolving rapidly, and some platform capabilities are still in active development.

File Attachments in Chat

Files cannot currently be uploaded directly into Ada conversations.

File Explorer Data Access

Data stored in your account (accessible through the Explorer application) is not directly accessible in chat workflows. Data first needs to be imported into a DataStar project or connected database.

DataStar and Cosmic Frog Integration

The Next Gen platform does not yet provide fully seamless integration of the DataStar and Cosmic Frog applications. For some processes, users will need to open these in the current platform (https://optilogic.app).

UI Rendering Requires the Next Gen UI Agent

Advanced inline visualizations and UI rendering features currently require selecting the Next Gen UI Agent explicitly.

Long Conversations Can Degrade Performance

As conversations grow longer, Ada may lose context, become repetitive, or produce less reliable responses.

Starting a fresh conversation for new workflows or projects generally improves results.

AI Responses Should Always Be Reviewed

Like all AI systems, Ada can occasionally produce incorrect or misleading outputs.

Always validate:

• optimization assumptions
• generated SQL
• data transformations
• KPI interpretations
• scenario recommendations

before using outputs in production or customer-facing work.

Session Stability

Leaving the platform idle for extended periods can interrupt workflows or produce unexpected behavior.

If the platform becomes unstable:

• refresh the session
• restart the conversation if needed

Other Helpful Resources

• Understanding Ada Credits
• The Modeler AI Agent
• The Data Cleansing AI Agent
• An overview of the Next Generation Optilogic Platform
• An overview of Optilogic's AI Agents and Utilities‍
• AI Agents: Architecture and Components‍
• Learn more about Cosmic Frog‍
• Learn more about DataStar

We hope you are going to have many productive conversations with Ada! Please do not hesitate to contact our Support team via support@optilogic.com if you have any questions or concerns.

Appendix – AI Data Security and Privacy

Applies to all Optilogic AI systems.

No confidential client information will be used as inputs or part of model training and validation datasets. In addition:

• Data Ownership: You retain ownership of your data. The data you input is not shared with any outside parties.
• No External Sharing: None of the data used when interacting with Optilogic Agentic AI will be shared or allowed to be used to train any LLM or model.
• Access Control: Access to your conversation history is limited to you and authorized Optilogic personnel. Your conversation data is not accessible to other users.
• Data Security: Optilogic employs industry-standard security practices to protect your data from unauthorized access and breaches.

Data Minimization: The amount of data shared with the AI provider depends on the task being performed. Optilogic's agents are engineered to query and pass only the minimum data required for each specific operation — ranging from structural metadata (table and column names, data types, statistical summaries) for schema-level tasks, to slices of actual data values for operations that require it, such as data cleansing, outlier detection, or name matching.

Optilogic does not transmit your entire dataset to the AI provider in a single operation. However, over the course of a session, the AI provider may process portions of your data as needed to complete the tasks you request.

No Model Training: Optilogic does not use your data to train AI models. Optilogic’s current AI provider (OpenAI) does not use API-submitted data for model training under their enterprise API terms. Refer to OpenAI policies here: https://openai.com/policies/.

Built-in Agent Safety Instructions: Optilogic agents include standing safety instructions in their core configuration to guard against prompt injection — attempts to manipulate agent behavior through user messages or data the agent processes. These instructions:

• Maintain platform rules regardless of override attempts made through conversation or through data in your models
• Treat query results, external files, and retrieved knowledge as content to analyze, not as commands to execute
• Decline requests to reveal or reconstruct system-level instructions
• Resist common manipulation techniques — including urgency, false authority, and roleplay scenarios — used to bypass safeguards
• These protections are instruction-based: they shape how the agent is directed to behave. They do not constitute a technical barrier, and they do not replace careful review of agent actions before approving high-impact operations.

Best Practices: Users should avoid including sensitive information (PII, credentials, etc.) in table/column names or prompts, as these are shared with the AI provider.

This documentation details how to connect and disconnect the Optilogic MCP connector using ChatGPT. To learn more about the Optilogic MCP Connector, please see The Optilogic MCP Connector Help Center article. It includes an explanation of what the connector is, how it can be used, example prompts, best practices, data handling and security details, and troubleshooting pointers.

Setting Up the Connector

Any user can add the connector to their own ChatGPT account and authenticate with Optilogic directly — no admin setup required.

Step 1: Turn on Developer Mode

In ChatGPT, go to your Account > Settings > Security and login, or navigate directly to https://chatgpt.com/#settings/Security. Scroll down to Developer Mode and toggle it on:

‍

Step 2: Start a New Plugin Connection

Go to Plugins in the menu at the top-left (or browse to https://chatgpt.com/plugins) and click the + icon in the top-right corner to add a new custom connector.

Step 3: Fill in the Optilogic Connector Details

Complete the New Plugin form as follows:

1. Name: Optilogic
2. Connection: https://mcp.optilogic.app/mcp
3. Authentication: leave at default of OAuth
4. Check the risk acknowledgement box
5. Click on the Create button

Step 4: Sign in to Optilogic

Clicking Create brings up an “Add Optilogic to ChatGPT” form, click on the “Sign in with Optilogic” button:

Complete the login with your Optilogic credentials:

Once logged into Optilogic, the Plugins form in ChatGPT will show following. You do not need to do anything else and can close out of here by clicking on the x in the top-left corner:

Step 5: Verify the Connection

In a new ChatGPT conversation, ask it to use the connector. For example: “Connect to Optilogic – which databases do you see in my account?”. Success will look similar to the following prompt and response, confirming the MCP connection is live and authenticated correctly:

Uninstalling the Connector

Should you need to disconnect from the Optilogic Connector, go to Plugins and click on the Optilogic connector in the list of Installed connectors:

Then click on the icon with 3 horizontal dots to open a context menu and choose Uninstall from this menu:

Please note that the connector will be uninstalled immediately without asking to confirm.

Use the steps outlined in the “Setting up the Connector” section above to re-connect to the Optilogic connector.

This documentation details how to connect and disconnect the Optilogic MCP connector using Claude. To learn more about the Optilogic MCP Connector, please see The Optilogic MCP Connector Help Center article. It includes an explanation of what the connector is, how it can be used, example prompts, best practices, data handling and security details, and troubleshooting pointers.

Setting Up the Connector

Any user can add the connector to their own Claude account and authenticate with Optilogic directly — no admin setup required.

Step 1: Add the Connector

Navigate directly to https://claude.ai/directory/optilogic, and Click on the Connect to Claude button:

Alternatively, in Claude, go to Account > Settings > Connectors > Add (right-top) > Browse Connectors, search for "Optilogic", and click on the Optilogic connector that is found. Then click on Connect to Claude.

Step 2: Log In to Optilogic

Clicking Connect to Claude redirects you to the Optilogic login screen. Sign in with your Optilogic credentials:

Step 3: Confirm the Connection

Once signed in, you are connected and you can close the Connectors screen. In a new Claude chat, try a test prompt to confirm everything is working: “Show me what databases you have access to in Optilogic.”:

Step 4: Allow Access

When Claude requests permission to use the connector choose to Always Allow, Allow once, or Deny.

‍

Disconnecting or Removing the Connector

Should you need to disconnect or remove the Optilogic Connector, please take following steps:

1. In Claude, go to your Account > Settings > Connectors and click on the Optilogic connector.
2. To disconnect without removing the connector, click on the Disconnect button – you will not have access to Ada from your Claude chats anymore, but you can easily re-connect when desired.
3. To completely remove the connector, click on the button with the 3 vertical dots and choose Remove. If you want to use the Optilogic connector again in future, you will need to go through the steps of the “Setting up the Connector” section above again.

When demand fluctuates due to for example seasonality, it can be beneficial to manage inventory dynamically. This means that when the demand (or forecasted demand) goes up or down, the inventory levels go up or down accordingly. To support this in Cosmic Frog models, inventory policies can be set up in terms of days of supply (DOS): for example for the (s,S) inventory policy, the Simulation Policy Value 1 UOM and Simulation Policy Value 2 UOM fields can be set to DOS. Say for example that reorder point s and order up to quantity S are set to 5 DOS and 10 DOS, respectively. This means that if the inventory falls to or below the level that is the equivalent of 5 days of supply, a replenishment order is placed that will order the amount of inventory to bring the level up to the equivalent of 10 days of supply. In this documentation we will cover the DOS-specific inputs on the Inventory Policies table, how a day of supply equivalent in units is calculated from these and walk through a numbers example.

In short, using DOS lets users be flexible with policy parameters; it is a good starting point for estimating/making assumptions about how inventory is managed in practice.

Note that it is recommended you are familiar with the Inventory Policies table in Cosmic Frog already before diving into the details of this help article.

Days of Supply Settings

The following 2 screenshots show the fields that set the simulation inventory policy and its parameters on the Inventory Policies table:

1. This inventory policy for product P1 at facility DC_1 is set to (s,S) which is often referred to as a minimum/maximum policy. When the inventory falls to the value of reorder point s or below, a replenishment order is placed to bring the inventory back up to the order up to value of S.
2. The reorder point s is set to 5 days of supply by setting the Simulation Policy Value 1 field to 5 and its UOM field to DOS.
3. The order up to quantity S is set to 10 days of supply by setting the Simulation Policy Value 2 field to 10 and its UOM field to DOS.

For the same inventory policy, the next 2 screenshots show the DOS-related fields on the Inventory Policies table; note that the UOM fields are omitted in these screenshots:

1. DOS Window and its UOM field – the number of days of (forecasted) demand that are used to calculate the 1 day of supply equivalent in units. Note that the default for the UOM field is hours, so it needs to be set to DAY if wanting to fill out a number in the DOS Window field that means days. In this example, the DOS Window is set to 10 days (the UOM field that is not shown is set to DAY). In practice, a DOS Window needs to be short enough to capture changes in order trends, but also long enough so that replenishments can keep up with customer orders.
2. DOS Leadtime and its UOM field – when using forecasted demand to calculate the 1 DOS equivalent, a lead-time can be set using these fields, so that the calculation of 1 DOS will not use the forecasted demand for the current day and immediately following days but is offset by this lead-time. This can account for the time it takes to get a replenishment order in, so the amount to reorder depends on future demand that will occur from when the replenishment arrives. Like for the DOS Window, note that the default for the UOM field is hours, so it needs to be set to DAY if wanting to fill out a number in the DOS Leadtime field that means days. Leaving this field blank is equivalent to setting it to 0, e.g. no lead-time is used for the DOS calculations.
3. DOS Review Period First Time – the first time during the simulation that the 1 DOS equivalent is being calculated. When left blank this is at the start of the simulation.
4. DOS Review Period and its UOM field – the time in between calculations of the 1 DOS equivalent. If set to 7 DAY for example, then the 1 DOS value is calculated once a week and it then stays at that value until the next DOS calculation 1 week later. Again, note that the default for the UOM field is hours, so it needs to be set to DAY if wanting to fill out a number in the DOS Review Period field that means days.
5. Forecast Type – this field specifies if the DOS calculations should use historical demand or forecasted demand. When set to Historical, the orders in the Customer Orders / Customer Order Profiles tables are used for the DOS calculations. When set to User-Defined, the forecasted demand that is set up using the User Defined Forecasts Data and User Defined Forecasts tables is used for the DOS calculations. Users can learn more about the Customer Orders / Customer Order Profiles tables in this help center article called “Adding Demand (Simulation)”. The User Defined Forecasts Data and User Defined Forecasts tables are covered below in the next section.
   1. Note that an important difference between using historical vs forecasted demand is that Customer Orders / Customer Order Profiles are entered at the customer-product level, whereas forecasted demand needs to be specified at the facility-product level. For historical demand specified in the Customer Orders / Customer Order Profiles tables, the demand to multiple customers that is filled by 1 facility will be automatically aggregated by Cosmic Frog for the purpose of inventory management.
6. DOS User Defined Forecast Name – when Forecast Type is set to User-Defined, this field specifies the name of the forecast (set up in the User Defined Forecasts Data and User Defined Forecasts tables, covered below) to be used for the DOS calculations.

User-Defined Forecasts

As mentioned above, when using forecasted demand for the DOS calculations, this forecasted demand needs to be specified in the User Defined Forecasts Data and User Defined Forecasts tables, which we will discuss here. This next screenshot shows the first 15 example records in the User Defined Forecasts Table:

1. Forecast Name – the name of the forecast being specified. Records with the same Forecast Name together make up a forecast.
2. Date – date and optionally time at which the forecasted demand occurs.
3. Forecasted Quantity and its UOM field – the amount of product that is forecasted to be demanded on the specified date.

Next, the User Defined Forecasts table lets a user configure the time-period to which a forecast is aggregated:

1. Forecast Name – this should match the name of a forecast specified in the User Defined Forecasts Data table.
2. Aggregation Strategy – select if a forecast should be rolled up to the day, week, month or year level.

DOS Calculations

Let us now explain how the DOS calculations work for different DOS settings through the examples shown in the next screenshot. Note that for all these examples the DOS Review Period First Time field has been left blank, meaning that the first 1 DOS equivalent calculation occurs at the start of this model (on January 1^st) for each of these examples:

1. For convenience’s sake, we are assuming that the historical demand (specified in the Customer Orders /Customer Order Profiles tables) rolled up to the facility-product combination is the same as the forecasted demand at this facility-product combination as set up in the User Defined Forecasts Data table. For January 1^st through January 5^th, the (forecasted) demand for DC_1 – P1 is 100 units, for January 6^th-10^th it is 200 units, for January 11^th-15^th it is 300 units. This pattern of increasing by 100 every 5 days continues in the future although not shown in the table above: 400 units for January 16^th-20^th, 500 units for January 21^st-25^th, etc.
2. When using historical demand with a 10 day DOS Window and 1 day DOS Review Period, the calculation of 1 DOS on January 1st uses the historical demand occurring during the 10 days before January 1^st: December 22^nd through December 31^st of the previous year. However, this model starts on January 1^st and there is no customer order data for these 10 days in December in the model. Therefore, the calculation of 1 DOS results in 0. Since DOS Review Period is set to 1 day, the next time the 1 DOS equivalent is calculated is on January 2^nd: there is now 1 day of history that the model will use for the calculation: the demand on January 1^st is 100, so the equivalent of 1 DOS on January 2^nd = 100 (sum daily demand Jan 1) / 1 (day) = 100. For the next DOS review on January 3^rd, there are 2 historical demand records available to use and the 1 DOS calculation is as follows: 200 (sum of daily demand Jan 1-2) / 2 (days) = 100. Since the demand does not change for several days, the average daily demand (or 1 DOS) does not change until the demand goes up to 200 on January 6^th. The 1 DOS calculation for January 7^th becomes: 700 (sum of daily demand Jan 1-6) / 6 (days) = 116.7. On January 11^th there is finally enough historical demand to use the full 10 days of the DOS window and the 1 DOS equivalent calculation becomes: 1,500 (sum daily demand Jan 1-10) / 10 (days) = 150. The calculation on Jan 12^th uses the demand for Jan 2-11: 1,700 (sum daily demand Jan 2-11) / 10 (days) = 170, etc.
3. The next record shows the results of the 1 DOS calculation when again using historical demand, but now with a 5 day DOS Window and a 5 day DOS Review Period. For the 1 DOS equivalent calculation for January 1^st there is again no history in the model, so it results in 0. But now, since the DOS Review Period is set to 5 days, the next DOS review is on January 6^th and the 1 DOS equivalent of 0 as calculated on January 1^st will be used until then as the 1 DOS equivalent. On January 6^th, the 1 DOS calculation is as follows: 500 (sum of daily demand Jan 1-5) / 5 (days) = 100. Again, it stays at this value of 100 throughout January 10^th, since the next review is on January 11^th. On this day, January 11, we use the demand for January 6-10 to calculate 1 DOS since the DOS Window is set to 5 days, so the result is: 1,000 (sum daily demand Jan 6-10) / 5 (days) = 200, etc.
4. This example and the next 2 use forecasted demand since the Forecast Type is set to User-Defined. For this record, the DOS Window is set to 10 days, there is no DOS Lead-time and the DOS Review Period is 1 day. For the DOS calculation on January 1^st, the model looks forward at the forecasted demand for the next 10 days starting on January 1: 1,500 (sum of daily demand Jan 1-10) / 10 (days) = 150. With a DOS Review Period of 1 day, the next 1 DOS equivalent calculation is on January 2^nd: 1,700 (sum daily demand Jan 2-11) / 10 (days) = 170, etc.
5. This next example also uses forecasted demand, a 10 day DOS Window, and 1 day DOS Review Period like the previous example discussed under bullet 4. The only difference is that in this example there is also a 5 day DOS Lead-time specified. This means that on January 1 we do not use the forecasted demand for Jan 1-10, but we offset it by 5 days to start on January 6. The 1 DOS equivalent calculated on January 1 is therefore: 2,500 (sum daily demand Jan 6-15) / 10 (days) = 250. Since DOS Review Period is 1 day, the next 1 DOS equivalent calculation is on January 2^nd and is as follows: 2,700 (sum daily demand Jan 7-16) / 10 (days) = 270, etc.
6. Our last example is the same as the previous one under bullet 5 with the 1 change that the DOS Review Period is changed to 5 days (from 1 day). The 1 DOS calculation on January 1^st is the same as for the previous bullet and results in 250. The 1 DOS equivalent stays at 250 until the next DOS review occurs on January 6^th, which uses the forecasted demand for January 11-20 and the 1 DOS equivalent calculation results in: 3,500 (sum daily demand Jan 11-20) / 10 (days) = 350. It again stays at this value for 5 days until the next DOS review on January 11^th, etc.

Inventory Policy using DOS – Numbers Example

Now that we know how to calculate the value of 1 DOS, we can apply this to inventory policies which use DOS as their UOM for the simulation policy value fields. We will do a numbers example with the one shown in the screenshot above (in the Days of Supply Settings section) where reorder point s is 5 DOS and order up to quantity S is 10 DOS. Let us assume the same settings as in the last example for the 1 DOS calculations in the screenshot above, explained in bullet #6 above: forecasted demand is used with a 10 day DOS Window, a 5 day DOS Leadtime, and a 5 day DOS Review Period, so the calculations for the equivalent of 1 DOS are the numbers in the last row shown in the screenshot, which we will use in our example below. In addition to this, we will assume a 2 day Review Period for the inventory policy, meaning inventory levels are checked every other day to see if a replenishment order needs to be placed. DC_1 also has 1,000 units of P1 on hand at the start of the simulation (specified in the Initial Inventory field):

1. The first record shows the same numbers for the equivalent of 1 DOS for January 1-15 as calculated in the last record of the previous screenshot and explained under bullet #6 above. From this 1 DOS equivalent, we calculate the reorder point, which is 5 DOS, and the order up to quantity, which is 10 DOS for each day in the January 1-15 period.
2. The next 3 rows show the starting inventory position on the day, the forecasted demand for that day, and the inventory position after the forecasted demand is subtracted from the starting inventory.
3. The inventory review record indicates if inventory is reviewed on that day. As mentioned, the Review Period is set to 2 days, so inventory is reviewed every other. The first review is at the start of the simulation on January 1^st, the next on January 3^rd, then January 5^th, etc.
4. On the days where inventory is reviewed, it is determined if a replenishment order needs to be placed, and if so, for how many units. To do so, the Inventory Position Post Demand is compared with the reorder point s and if it is at the value of the reorder point or below, a replenishment order will be placed. If an order is placed, the amount will be so that the inventory position is brought back up to the value of the order up to quantity S. On January 1^st, the reorder point s is 1,250 and the inventory position post demand is 900. Therefore, a replenishment order will be placed as the inventory position is below the reorder point (900 < 1,250). The order up to quantity S is 2,500 on January 1^st, so 2,500 (order up to) – 900 (inv position post demand) = 1,600 units will be ordered. On January 3^rd and 5^th, the inventory positions after filling demand are greater than the reorder point (2,300 > 1,250 and 2,100 > 1,250, respectively). At the next review on January 7^th, a replenishment order is placed as the inventory position post demand (1,700) is less than the reorder point (1,750). The amount to reorder is calculated to be 3,500 (order up to quantity S) – 1,700 (inventory position post demand) = 1,800, etc.
5. The inventory position end indicates the inventory position at the end of the day and is used as the starting inventory position for the next day.

Cosmic Frog supports importing and exporting both CSV and Excel files directly through the application. This enables users to for example:

• Bulk upload data that was exported to CSV/Excel from the organization’s ERP systems to accelerate model building in Cosmic Frog.
• Easily update changed data and add new data.
• Export a subset of output tables for quick analysis in tools many users are familiar with.

In this documentation we will cover how users can import and export data into and out of Cosmic Frog, and illustrate this with multiple examples.

Importing Data

There are 2 methods of importing Excel/CSV data into Cosmic Frog’s input tables available to users:

1. Upsert: when using this method, data is updated for records that already exist in the Cosmic Frog table and new records are inserted to the table.
2. Replace: all existing data in the table is first deleted and then the data from the file being imported is added to the table.

Pointers on how data to be imported needs to be formatted will be covered first, including some tips and call outs of specifics to keep in mind when using the upsert import method. Next, the steps to import a CSV/Excel file will be walked through step by step.

Data Preparation Pointers

Data is mapped from CSV/Excel files based on matching column names and table names matching to the file name (CSV) or worksheet name (Excel):

• Data (both CSV or Excel) to be imported into an input table in a Cosmic Frog model needs to have column names which match the names of the columns in the Cosmic Frog table that will be imported to exactly.
  • If you create a custom column in your import file, you must create the same name column in the input table to avoid import failures. There is no set limit as to the number of custom columns you can create.
• The name(s) of the CSV file(s) and of the Excel worksheet(s) to be imported need to exactly match the name(s) of the Cosmic Frog input table(s) the data will be imported into. The name of the Excel workbook containing the worksheets to be imported does not need to match anything in Cosmic Frog. We do, however, recommend using descriptive names for these workbooks which will often include the model’s name, and an indication of the version/changes.
  • An exception to this is when importing 1 CSV file or an Excel file with just 1 worksheet at a time, then the name of the file/worksheet does not have to match the name of the table to be imported to.

Data preparation tips:

• Export the table(s) to be updated to CSV or Excel first to generate a template (see the “Exporting to CSV/Excel Files” section further below on how to do this). Then populate the template with the relevant data before importing the file back in.
• There is no need to have all columns that are present in the table in Cosmic Frog in the CSV/Excel data, just at least one of the table’s key columns, plus any other columns that have data in them is sufficient. Key columns can be recognized in the Cosmic Frog input tables by the key icon to the left of the column name and their column names are in bold, as shown in the screenshot below. One notable exception to this is the Notes field (present in almost all input tables): even though it does not have the key icon and the column name is not in bold, it is part of the primary key of all tables that have a Notes field.

CSV vs Excel: CSV files only have 1 “worksheet”, so it can only contain data to be imported into 1 table, whereas Excel files can have multiple worksheets with data to be imported to different tables in Cosmic Frog.

Please take note of how existing records are treated when using the upsert import method to import to a table which already has some data in it:

• If there are records in the file that is upserted that have matching values for all of the table’s primary key columns, these records’ non-primary key columns are updated with the values specified in the file that is upserted.
  • If a primary key column’s value is blank in the existing record, then having a blank value for it in the file to upsert or not having this column at all in the file to upsert are both considered to be matching with the existing record’s primary key column value.
  • If a non-primary key column in an existing record has a value set already, say for example 2 for UnitVolume on the Products table for a product with Product Name “Basketball” (Product Name and Notes are the primary key columns on the Products table), and the file that is upserted into the Products table has a record with Product Name = Basketball, but does not contain the UnitVolume column in the data, the existing value of 2 for UnitVolume persists.
• Existing records for which there are no records in the upserted file where the values of the primary key columns match are left as is.
• Records in the upserted file which do not have the values of all primary key columns match with those of an existing record are added as new records to the table (i.e. appended).

We will illustrate these behaviors through several examples too.

Importing a CSV/Excel File

Users can import 1 or multiple CSV or Excel files simultaneously, please take note of how the import will work for following situations:

• If 1 CSV file or an Excel file with 1 worksheet is imported – it is imported to the active table regardless of whether the name of the file/worksheet matches the active table’s name.
• If multiple CSV files are imported – based on the names of the CSV files, they are imported to the Cosmic Frog input tables that have matching names, regardless of which table the active table is or which table(s) are selected in the input tables list.
• If an Excel file with multiple worksheets or multiple Excel files are imported – all the worksheets that have a name matching an input table are imported to those Cosmic Frog input tables. This is again regardless of which table the active table is, or which table(s) are selected in the input tables list. Please note:
  • If multiple Excel files are being imported and 2 or more of them contain worksheets with the same Cosmic Frog table name, the outcome of the import becomes unpredictable as the user does not know beforehand the order in which the imports are applied (e.g. they could both be updating the same existing record with different numbers and in that case last change wins). Therefore, users should take care to prevent situations like these.
  • Known issue: if there is an entirely empty worksheet in an Excel file that is imported, the worksheet(s) after this one are not imported.

Once ready to import the prepared CSV/Excel file(s), users have 2 ways of accessing the import and export methods: from the File menu in the toolbar and from the right-click context menu of an input table. It looks like this from the File menu to import a file:

1. Make sure to be in Cosmic Frog’s Data module. If another module is active, click on the Module menu icon (the 3 horizontal bars) and choose the second option Data.
2. When importing 1 CSV file or an Excel file with 1 worksheet it is important to first make sure the table the data should be imported to is the active table (this is not needed for importing multiple CSV files or multiple Excel file(s)). Users can do this by:
   1. Clicking on the name of the table in the Input Tables list, or
   2. Making sure the tab of this table is the active one by clicking on the tab.
3. Click on the File menu in the toolbar.
4. Select either Import File (UPSERT) or Import File (REPLACE) depending on which import method is desired.

And when using the right-click context menu the steps to import a file are as follows:

1. Again, make sure to be in Cosmic Frog’s Data module. If another module is active, click on the Module menu icon (the 3 horizontal bars) and choose the second option Data.
2. Make sure the Input Tables list is showing by clicking on the square grid icon.
3. When importing 1 CSV file or an Excel file with 1 worksheet it is important to right click on the table the data should be imported to (this is not needed for importing multiple CSV files or importing multiple Excel file(s)).
4. Click on File menu in the context menu.
5. Select either Import File (UPSERT) or Import File (REPLACE) depending on which import method is desired.

When using the replace import method, a confirmation message will now be shown on which the user can click Import to continue the import or Cancel to abort.

Next, a file explorer window opens in which the user can browse to and select the CSV/Excel file(s) to import:

1. Navigate to the folder where the file(s) to import are located.
2. Cosmic Frog currently can import Excel files with .xlsx, .xls, and .xlsm extensions, and CSV files.
3. Select the file(s) to import by clicking on them (holding the Ctrl-button down if selecting more than 1 file).
4. Click on Open when ready to import or Cancel to abort the import (buttons not shown in screenshot as they are hidden by the file extension drop-down).

Once the import starts, a status message shows at the top of the active table:

The Model Activity log will also have an entry for each import action:

1. To open the Model Activity log, click on the dark blue speech bubble located at the top right of your Cosmic Frog screen.
2. The pane indicates that this is the Model Activity list.
3. The specific activity we scrolled down to shows a successful File Upsert action.
4. More details are listed, including the number of records updated (0 here), the number of records inserted (6 here), and when the activity happened.

Users can see the results of the import by opening and inspecting the affected input table(s), and by looking at the row counts for the tables in the input tables list, outlined in green in this screenshot:

Example 1 – Use Replace to Bulk Import Data for First Build Model

A common way to start building a new model in Cosmic Frog is to make use of the replace import method to populate multiple tables simultaneously with data from Excel or CSV files. These files have typically been prepared from ERP extracts which have been manipulated to match the Cosmic Frog table and column names. This way, users do not need to enter data manually into the Cosmic Frog input tables, which would be very laborious. Note that it can be helpful to first export empty tables from a new, empty Cosmic Frog model to have a template to start filling out (see the “Exporting to CSV/Excel Files” section further below on how to do this).

‍

Starting with an empty new model in Cosmic Frog:

1. No row counts are shown for any of the input tables, meaning these table do not have any data in them.
2. The user is going to use the Import File (REPLACE) option from the File menu in the toolbar to import the file shown in the next screenshot.

The user has prepared the following Excel .xlsx file:

1. The name of the file is Prod_Cust_Fac_CFImport_2025_02_24.xlsx.
2. It has 3 worksheets, each of which has a name that matches the name of a Cosmic Frog input table: Customers, Facilities, and Products.
3. The Customers worksheet is showing and we can see that the column names are matching those of the Customers input table in Cosmic Frog. Note that only 4 columns are included and populated, this is sufficient; columns which would have only blank values do not need to be explicitly defined and imported. The customername column is part of the table’s primary key and should be included for each record.

After importing this file into Cosmic Frog, we notice that the Customers, Facilities and Products tables now have row counts that match the number of records we had in the Excel file that was used for the import, and we can open the individual tables to see the imported records:

Example 2 – Replace Entire Products Table

Consider a user who is modelling a sports equipment company and has populated the Products table of a Cosmic Frog model with 8 products as follows:

After working with the model for a while, the user realizes a few things:

1. The naming convention of the products could be improved to be more structured and allow for easier filtering, model building, and output analysis.
2. The Unit Price column is not populated, but executives are interested in including this to have the model calculate revenues and profit too.
3. There are 2 products the company is considering adding to its offering, basketballs and baseballs, and these need to be added to the model to be included in certain scenario runs.

As item number 1 will change the product names, a column that is part of the primary key of the Products table, the user will need to use the replace import method to make these changes as the upsert method does not change the values of columns that are part of the primary key. Following is the .xlsx file the user prepares to replace the data in the Products table with:

1. All Product Names are now prefixed with first an abbreviation indicating the type of product (FG meaning finished good), followed by the product category: balls, rackets, and bats here.
2. The Unit Price field is populated for all products, while ensuring that the original data of Status and Unit Value is included too. Keeping this data in here is important since the replace will delete all data from the existing table and then add the data from this worksheet.
3. The 2 products to be included in specific scenarios are listed in the bottom 2 records, with Status = Exclude, and the Notes field is populated for easy filtering when setting up the scenario(s) that change the status of these fields to Include.

After importing the file using the replace method, the Products table looks like this:

We see the records are the exact same as what was contained in the Products.xlsx file that was imported, and the row count for the Products table has correctly gone up to 10 with the 2 new products added.

Example 3 – Upsert to Products Table

Continuing from the Products table in the last screenshot above, the user now wants to make a few additional changes as follows:

1. They have been made aware the Unit Value and Unit Price values of Squash Balls are incorrect in the original data, and should be changed to 6 and 12, respectively.
2. The Rackets category should by default be excluded from the model runs going forward as the company is phasing this category out.
3. A new product, Softballs, to be included in a specific scenario only, should be added to the Products table.

To make these changes to the Products table, the user prepares the following Products file to be upserted to the Products table, where the green numbers in the screenshot below match the items described in the bullet point list directly above:

After using the upsert import method for this file into the Products table, it contains following records. The ones changed / added are listed at the bottom:

In the boxes outlined in green we see that all the expected changes and the insertion of the 1 new record have been made.

Example 4 – Replace Using Invalid Data

Let us also illustrate what will happen when files with invalid / missing data are imported. We will use the replace import method for the example here, but similar results will be seen when using the upsert method. Following screenshot shows a Products table that has been prepared in Excel, where we can see several issues already: a blank Product Name, a negative value for Unit Price, etc.

After this file is imported to the Products table using the replace method, the Products table will look as follows:

The cells that are outlined in red contain invalid values. Hovering over each cell will show a tooltip message describing the problem.

1. The Product Name field is left blank, it should contain a unique name for each product. Hovering over this cell following tooltip text is shown: Value is required.
2. The Status field is set to Potential which is not a valid option for this field. Hovering over this cell following tooltip text is shown: Allowed values are [Include,Exclude].
3. The Unit Value field is set to Test, it should however be a numerical value. Hovering over this cell following tooltip text is shown: Should be of type double-precision. Cannot be negative.
4. The Unit Price field is set to -5, it should however be a positive value. Hovering over this cell following tooltip text is shown: Cannot be negative.

For tables with many records, it may be hard to find the fields in red outline manually. To help with this, there is a standard filter users can apply that will show all records that have 1 or multiple input data errors:

1. Open the Filter menu in the toolbar.
2. Select the last option in the drop-down menu “Show Input Data Errors”.
3. The table is now filtered to only show records where 1 or multiple fields contain data errors.

In conclusion, Cosmic Frog will let a user import invalid data, and then help identify the data issues with the red outlines, hover over tooltips, and the Show Input Data Errors filter.

Example 5 – Upsert Does Not Edit Values of Primary Key Columns

Consider following Transportation Policies table:

1. The primary key of the table consists of the 4 fields outlined in green, Origin Name, Destination Name, Product Name, and Mode Name, plus the Notes field (not shown).
2. There are 4 records set up for which the Product Name field has been left blank, meaning each policy applies to all products present in the model.

There is now a change where from MFG_1 all Racket products need to be shipped by Parcel for a fixed cost of $50. The user creates 2 Named Filters (see the Named Filters in Cosmic Frog help center article) in the Products table: 1 that filters out all racket products (those products that have a product name that start with FG_Racket) which is named Rackets and 1 that filters out all non-racket products (those products that do not contain racket in the product name) which is named AllExceptRackets. Next, the user prepares following TransportationPolicies.csv file to upsert into the Transportation policies table with the intention to update the first 2 records in the existing table to be specific for the AllExceptRackets products and add 2 new ones for the Rackets products:

1. As these policies now need to behave differently for Rackets vs AllExceptRackets products, the Product Name field is used and set to the names of these named filters to apply to those products.
2. For the Rackets records, Mode Name is set to Parcel and Fixed Cost to 50.

The result of using this file to upsert to the Transportation Policies table is as follows:

1. As the Product Name is part of the table’s primary key, and the primary key fields do not match entirely for the MFG_1 to DC_1 / DC_2 Truck mode records (origin name, destination name, mode name, and notes match, but product name does not) new records are created and inserted:
   1. The existing records are not changed since there are no records in the upserted file that match the primary key fields exactly (the product name is different).
   2. These are the new records added for MFG_1 to DC_1 / DC_2 Truck mode records, for the products in the AllExceptRackets group. Note that no costs are associated with this record as the user expected the upsert to update the existing records which have costs on them ($1 per unit per mile).
2. These records for the Rackets products were added (inserted) to the Transportation Policies table as was the intention.

This example shows that users need to be mindful of which fields are part of the table’s primary key and remember that values of primary key fields cannot be changed by the upsert import method. An example workflow that will achieve the desired changes to the Transportation Policies table is as follows:

1. Export the entire Transportation Policies table to Excel or CSV, which is explained in the next section below.
2. Update the 2 existing records for MFG_1 to DC_1 / DC_2 using the Truck mode: set the Product Name to AllExceptRecords.
3. Add 2 new records for the MFG_1 to DC_1 / DC_2 Parcel mode where Product Name = Rackets; ensure to set the Fixed Cost field to $50.
4. Save the file.
5. Use the replace method to import this file back into the Transportation Policies table.

Exporting to CSV/Excel Files

It is possible to export a single table or multiple tables (input and output tables) to CSV or Excel from Cosmic Frog. Similar to importing data from CSV/Excel, users can access the export options in 2 ways: from the File menu in the toolbar and from the context menus that come up when right-clicking on tables in the input/output/custom tables lists.

Please note:

• One important difference between the 2 ways of accessing the export options is that it is only possible to export multiple tables simultaneously by using the File menu in the toolbar; right-clicking on a table and using the context menu to export to CSV/Excel is limited to one table at a time.
• If an output table is filtered when exporting it, only the filtered rows are exported.

Export Multiple Tables to Excel

The steps to export multiple tables to an Excel file are as follows:

1. Select the tables to export from the Data module in Cosmic Frog, holding down the Ctrl-button to select multiple tables. This can be from the Input Tables section (as shown here), from the Output Tables section, or the Custom Tables section. In this example, the user has selected three input tables: Customers, Facilities, and Products.
2. Since the user wants to export these 3 selected tables to Excel in one go, they need to use the Export Excel option from the File menu in the toolbar.

Once the export starts, following message appears at the top of the active table:

Once the export is complete, the exported file can be found in the folder where the user’s downloaded files are saved:

When exporting multiple tables to Excel or CSV, the downloaded file will be a .zip file with an automatically generated name based on the model’s Cosmic Frog ID. Extracting the zip-file will show an .xlsx file of the same name, which can be opened in Excel:

1. The name of the file which was autogenerated by Cosmic Frog. Here it is also indicated that the file is opened in “Protected View” mode.
2. An explanation of the Protected View mode is given here; the user can choose to click on Enable Editing to be able to work with the contents of the file.
3. There are 3 worksheets in the file, which match the names of the exported Cosmic Frog tables.
4. The Customers worksheet is showing and we see that the column names are those used in Cosmic Frog (just converted to be all lowercase). We also notice that all columns have been exported, not just the ones that are populated.

Export Multiple Tables to CSV

These are the steps to export multiple tables to CSV:

1. In this case, the user wants to export multiple output tables to CSV, so the Output Tables section of the Data module is selected.
2. The user has selected 2 tables, the Simulation Order Report and the Simulation Shipment Report.
3. To export to CSV, the user chooses the Export CSV option from the File menu.

When the export starts, the same “File is exporting…” message as shown in the previous section will be showing at the top of the active table. Once the export process is finished, the exported file can again be found in the folder where the user’s downloaded files are saved:

The file is again a zip-file, and it has the same name based on the model’s Cosmic Frog ID, just appended with (1), as there is already a zip-file of the same name in the Downloads folder from the previous export to Excel. Unzipping the file creates a new sub-folder of the same name in the Downloads folder:

1. The sub-folder created in the Downloads folder which has the same auto-generated name as the zip-file.
2. The 2 output tables exported as CSV. Their names match the names of the output tables that were exported.

Export Single Table to Excel

Exporting a single table to Excel can also be done from the File menu, in the same way as multiple tables are exported to Excel, which was shown above in the “Export Multiple Tables to Excel” section. Now, we will show the second way of doing this by using the context menu that comes up when right-clicking on a table:

1. The user wants to export 1 output table to Excel, so the Output Tables section of the Data module is selected by clicking on the round grid icon.
2. The user wants to export the Simulation Shipment Report and right-clicks on this table.
3. Export Excel is selected from the File menu.

When the export starts, the same “File is exporting…” message as shown above will be showing at the top of the active table. Once the export process is finished, the exported file can again be found in the folder where user’s downloaded files are saved:

The name of the exported CSV file matches that of the table that was exported.

Export Single Table to CSV

Exporting a single table to CSV can also be done from the File menu, in the same way as multiple tables are exported to CSV, which was shown above in the “Export Multiple Tables to CSV” section. Now, we will show the second way of doing this by using the context menu that comes up when right-clicking on a table:

1. The user wants to export the Transportation Policies input table to Excel. When looking at this table, we notice it is filtered:
   1. At the top of the table, it is indicated that only 27 of the 8,189 rows in the table are being shown.
   2. We see the 2 filter tags for Origin Name and Destination Name at the top right of the table – these are the 2 tables that have filter criteria on them.
   3. The filter icons to the right of the Origin Name and Destination Name column names are blue, indicating these columns are filtered. This icon is black for non-filtered columns (like Product Name in this screenshot).
2. The user right-clicks on the Transportation Policies input table to bring up the context menu.
3. Export CSV is chosen from the File menu.

When the export starts, the same “File is exporting…” message as shown above will be showing at the top of the active table. Once the export process is finished, the exported file can again be found in the folder where user’s downloaded files are saved:

For single tables exported to CSV, the name of the file is the same as the name of the exported table. If the Cosmic Frog table was filtered, the file name is appended with “_filtered” like it is here to remind the user that only the filtered rows are contained in this exported file.

Questions or feedback? Please feel free to contact the Optilogic support team on support@optilogic.com.

Overview

Cyclo is Optilogic’s new Multi Echelon Inventory Optimization (MEIO) engine within Cosmic Frog. It helps supply chain teams determine where safety stock should be held across a network, how much is needed at each stage, and how service levels impact total safety stock cost and responsiveness.

This video gives a quick overview of how to use Cyclo; it uses the Demo Model described further down in this documentation:

Quick Start

If you just want to get going with Cyclo as quick as possible, follow these steps:

1. Set the Technology Filter at the top in Cosmic Frog to only show tables and fields used by Cyclo
2. Populate the core input tables:
   1. Customers
   2. Facilities
   3. Products – set Unit Value
   4. Transportation Policies – set Transport Times
   5. Inventory Policies
   6. Customer Orders or Customer Order Profiles
   7. Inventory Settings – set Target Service Level and Service Type
   8. Model Settings – set Inventory Carrying Cost Percentage
3. Validate the model to ensure lead times, sourcing relationships, and units of measure are complete and consistent.
4. Create one or more scenarios to compare service levels, lead times, sourcing strategies, or network configurations.
5. Run Cyclo from the Run Settings window by selecting the desired scenarios.
6. Review results in the Inventory Network Summary and Inventory Safety Stock Summary tables.
7. Compare total safety stock, holding cost, and inventory positioning across scenarios to evaluate network-wide trade-offs.

What is MEIO?

Multi Echelon Inventory Optimization (MEIO) is a planning approach used to optimize safety stock across an entire supply chain network.

Cyclo, the MEIO engine, is designed to optimize safety stock placement across multi-stage supply chains that may include suppliers, manufacturing plants, distribution centers, and customer-facing locations. Instead of optimizing each node independently, Cyclo evaluates the entire network simultaneously so organizations can reduce total safety stock while maintaining desired service levels.

Cyclo uses a Guaranteed Service Model (GSM) approach to optimize service-time relationships between facilities and derive recommended safety stock levels.

Why Cyclo Matters

Cyclo helps organizations answer key supply chain questions such as:

• Where should safety stock be held?
• How much safety stock is actually needed?
• Which facilities should buffer variability?
• How do lead times affect safety stock requirements?
• How can service levels be maintained while reducing cost?

By optimizing safety stock placement across the entire network, Cyclo can help organizations:

• Reduce total inventory carrying costs
• Improve customer service performance
• Reduce duplicated safety stock
• Increase resilience to variability
• Better understand network bottlenecks

Cyclo is especially valuable for:

• Complex global supply chains
• Distribution-heavy operations
• Networks with uncertain demand

Cyclo vs. Dendro

Both Cyclo and Dendro support inventory optimization workflows in Cosmic Frog, but they are designed for different planning problems.

In practice both can be used together:

1. Cyclo determines optimal safety stock placement and levels across the network.
2. Dendro helps operationalize inventory policies and ongoing planning decisions.

How Cyclo Works

Cyclo uses a Guaranteed Service Model (GSM) approach. Rather than directly optimizing safety stock quantities, Cyclo optimizes service-time commitments between facilities. Those service-time decisions are then translated into safety stock requirements.

Core Concepts

Target service level

Represents your risk tolerance – balancing the cost of holding extra buffer inventory against the risk and cost of lost sales. This is a user input. Two risk measures are available:

• Type 1 (cycle service level): measures the probability of having zero stockouts during a replenishment cycle.
• Type 2 (fill rate): measures the proportion of total demand fulfilled immediately from available stock.

Service Type 1 is a stricter measure than Type 2 and will in most cases lead to more safety stock.

Incoming Service Time (SI)

Time a facility expects upstream suppliers to deliver material. This is a decision variable in the optimization

Fixed Lead Time (T)

Time a facility needs to replenish – typically transport time from the upstream location to the facility and/or production/processing time at the facility. These are model inputs.

‍

Outgoing Service Time (S)

Time a facility promises to deliver to downstream customers. This is a decision variable in the optimization.

Net Replenishment Time (NRT)

The effective time window over which demand uncertainty accumulates.

Guaranteed Service Model

In a Guaranteed Service Model (GSM), each facility commits to serving downstream nodes within a defined service time. The effective exposure to uncertainty is the Net Replenishment Time (NRT):

NRT = Incoming Service Time + Fixed Lead Times − Outgoing Service Time

As NRT increases, more uncertainty accumulates and more safety stock is typically required.

Cyclo evaluates many combinations of incoming and outgoing service times across the network to find the lowest total safety stock holding cost, while reaching the target service level. The optimization is not changing any fixed lead times. Instead, it is strategically deciding where responsiveness should exist in the network.

Example: Optimizing Safety Stock Placement Across a Network

Consider a product with the following flow path:

Manufacturer → Distribution Center → Customer

Assume the following fixed lead times:

• Transportation time from Manufacturer to Distribution Center (DC) = 4 days
• Production/processing times at Manufacturer and DC are both 0 days
• Transportation time from DC to Customer = 1 day

The total physical replenishment lead time across the network is therefore 5 days.

These lead times are inputs to the model and are not optimized. What Cyclo optimizes are the service-time commitments between stages. Specifically:

• Incoming Service Time (SI) – at the Manufacturer and DC in this example
• Outgoing Service Time (S) – at the Manufacturer and DC in this example

These service times are optimized with the goal to minimize total safety stock holding cost across the network.

In the next example scenarios:

• We assume the Distribution Center outgoing service time as fixed at 0 days, because the customer’s orders need to be fulfilled immediately upon placement to reach the required target service level.
• The Manufacturer outgoing service time reflects how quickly the Manufacturer replenishes the DC.
• The DC incoming service time reflects how long the DC expects replenishment from the Manufacturer.

Scenario A – Most Safety Stock at the DC

Manufacturer ----> DC (5 days safety stock) ----> Customer

Interpretation:

• Because the DC must respond immediately while replenishment may take 5 days, most uncertainty buffering occurs at the DC.
• The DC absorbs nearly all demand uncertainty.
• Inventory is positioned close to customers.
• Customer responsiveness is maximized.
• Downstream inventory investment is higher.

This approach is common in highly responsive distribution networks.

Scenario B – Balanced Buffering

Manufacturer (2 days safety stock) --> DC (3 days safety stock) --> Customer

Interpretation:

• The DC buffers 3 days of uncertainty.
• The remaining uncertainty buffering shifts upstream to the Manufacturer.
• Inventory buffering is shared across the network.
• Less inventory is concentrated downstream.
• Total cost may decrease depending on holding costs and variability.

Scenario C – More Upstream Buffering

Manufacturer (4 days safety stock) --> DC (1 day safety stock) --> Customer

Interpretation:

• Because the DC can be replenished quickly, it only needs to buffer 1 day of uncertainty.
• Most uncertainty buffering shifts upstream to the Manufacturer.
• Downstream inventory requirements are reduced.
• Total carrying cost may decrease if upstream storage is less expensive.
• The network becomes more dependent on transportation reliability.

Key Insights

The total physical replenishment exposure is driven by the same 5-day total network lead time in all 3 scenarios.

What changes is:

• where uncertainty is buffered,
• where safety stock is held,
• and which combination minimizes total network inventory cost.

Cyclo evaluates many combinations of:

• incoming service times,
• outgoing service times,
• inventory positioning,
• holding costs,
• and demand variability

to determine the optimal inventory strategy across the network.

Without MEIO, organizations often duplicate safety stock across multiple locations and optimize inventory independently at each node. Cyclo instead evaluates the network holistically and strategically concentrates inventory where it is most cost-effective, while achieving the required service level.

Cyclo Inputs and Outputs Summary

The following diagram summarizes the inputs and outputs of the Cyclo engine; they will be covered in more detail in the Cyclo in Cosmic Frog section that follows.

Cyclo in Cosmic Frog

The following workflow provides a step-by-step approach for configuring and running Cyclo.

Step 1 – Populate Input Tables

‍

The following table provides an overview of the input tables used by Cyclo, whether they are required, and their purpose. Further below, several screenshots show examples of some of the main inputs in Cosmic Frog.

‍

‍

‍

The following screenshots show several input tables with key Cyclo fields.

Products Table

‍

Inventory Policies Table

Transportation Policies Table

‍

Customer Orders & Customer Order Profiles

Demand can be specified in either of the Customer Orders and Customer Order Profiles tables. If the Customer Orders table is populated it will be used and the Customer Order Profiles table will be skipped in that case. If the Customer Orders table is blank, the Customer Order Profiles table will be used.

• Customer Orders – specify historical orders, Cyclo will calculate the demand statistics from these
• Customer Order Profiles – specify a distribution that represents the demand and its variability for the customer-product combination, plus set the time between orders

Inventory Settings Table

‍

‍

Model Settings Table

‍

Step 2 – Validate Inputs

Before running Cyclo, verify that the supply chain network is fully configured. Recommended validation checks:

• All facilities are connected correctly
• Product flows are complete from farthest upstream source to most downstream demand location
• Transportation relationships exist
• Lead times are populated
• Demand data is available
• Units of measure are consistent

You can also use Cosmic Frog’s Integrity Checker and filter the results where the Relevant Technology field contains Cyclo.

Step 3 – Run Cyclo

Once the model has been built, you can optionally configure additional scenarios to run. Here 1 additional scenario is added besides the Baseline:

1. The Baseline scenario does not contain any scenario items; it will use all the data of the input tables as is. Note that the Technology has been switched to Cycle, indicated by the light blue Cyclo icon to the right of the scenario name.
2. A scenario named “Baseline-Type1 has been added. It contains 1 scenario item named “Type1”, which changes the Service Type (set to Type 2 in the Inventory Settings table) to Type 1. It is configured as follows:
   1. Table Name is set to Inventory Settings, since this is the table on which we want to change some data.
   2. In the Actions field, the ServiceType field’s value is set to Type1.
   3. No Conditions are used, meaning that the change will apply to all records in the table (only 1 present).

After inputs are validated and scenarios set up, users can kick off their Cyclo optimization run by clicking on the green Run button at the top right in Cosmic Frog, which brings up the Run Settings modal:

During execution, Cyclo processes:

• Demand propagation through the network
• Service-time relationships
• Net replenishment calculations
• Safety stock positioning
• Cost minimization logic

The optimization engine evaluates inventory decisions holistically across the network rather than independently by node.

‍

‍

Step 4 – Review Results

After the optimization is completed, review the generated outputs.

The Cyclo outputs are in 2 tables, Inventory Network Summary and Inventory Safety Stock Summary, and include:

• Safety stock recommendations
• Service-time commitments
• Inventory policy recommendations
• Total cost and cost breakdowns

Understanding Cyclo Outputs

Cyclo outputs help users understand recommended inventory placement, service-time commitments, and total network inventory cost tradeoffs.

Inventory Network Summary Table

The Inventory Network Summary summarizes results by scenario:

This helps users:

• Compare scenarios
• Quantify savings opportunities
• Evaluate trade-offs

Inventory Safety Stock Summary Table

The Inventory Safety Stock Summary shows detailed results at the product x location level, by scenario:

The 4 screenshots in the next sub-sections are of additional fields on the same table and do not always show the fields of the screenshot above again.

Demand Classification

Safety Stock and Cost Breakdown

The recommended safety stock reflects:

• Demand variability
• Lead times
• Service level targets
• Network dependencies

Note that another field not shown in the screenshot, Holding Cost, is available in this table too. Its value is the holding cost for 1 unit of product at that location for the length of the model run. The Holding Cost Contribution is calculated as this Holding Cost value multiplied with the Safety Stock value.

Service Times

These values represent:

• Expected upstream responsiveness
• Promised downstream responsiveness
• Strategic inventory positioning decisions

Inventory Policies

Cyclo can recommend inventory policies and their parameters:

• R,Q policies – policies with a fixed reorder point, R, and a fixed order quantity, Q.
  • The recommended value for R is specified in the Policy Value 1 field
  • The recommended value for Q is specified in the Policy Value 2 field
• s,S policies – policies with a fixed reorder point, s, and an order-up-to quantity, S.
  • The recommended value for s is specified in the Policy Value 1 field
  • The recommended value for S is specified in the Policy Value 2 field

These policies help operationalize inventory decisions.

Interpreting Results

When reviewing Cyclo outputs, focus on patterns across the network rather than individual locations.

Questions to ask include:

• Which facilities are acting as inventory buffers?
• Where is variability accumulating?
• Are safety stock positions aligned with strategy?
• Which nodes drive most inventory holding cost?
• How sensitive are results to service levels?

‍

Best Practices

Start with Clean Data

Safety stock optimization quality depends heavily on the quality of the data.

Recommended practices:

• Validate lead times
• Confirm demand variability calculations
• Standardize units
• Verify network paths
• Remove obsolete products

Run Scenario Comparisons

Cyclo is especially valuable for scenario analysis.

Examples include:

• Alternative service-level targets
• Supplier lead-time changes
• Transportation changes
• Facility additions or removals
• Demand volatility changes

Scenario comparisons help quantify operational tradeoffs.

Focus on Network-Wide Performance

MEIO is fundamentally a system-wide optimization problem; avoid evaluating locations independently. The best global solution may intentionally increase inventory at one node in order to reduce much larger inventory requirements elsewhere.

Collaborate Across Functions

Cyclo outputs are most valuable when reviewed collaboratively by:

• Supply chain planners
• Inventory analysts
• Manufacturing teams
• Procurement teams
• Transportation planners
• Finance stakeholders

Common Questions

Why does Cyclo place more inventory at upstream locations?

In many networks, upstream buffering can reduce downstream safety stock due to variability evening out when aggregating demand from multiple downstream locations (pooling effect). This lowers the total inventory holding cost. Cyclo evaluates these trade-offs automatically.

Does higher service always mean more inventory?

Generally, yes. Higher service-level targets reduce allowable stockout risk, which usually increases safety stock requirements.

Why are service times optimized instead of inventory directly?

The Guaranteed Service Model simplifies the optimization problem and provides a scalable framework for network-wide inventory positioning. Safety stock is derived from optimized service-time relationships.

Demo Model

We will now walk through a Western Europe based life-size template Cyclo model. This model, Cyclo – MEIO, can also be copied to your own account from the Resource Library: Cyclo - MEIO model on the Resource Library.

In this model, we will examine the impact of varying the target service level, reduced demand variability, reduced transport lead-time, and only allowing safety stock to be held at customer facing DCs.

Overview

The following map shows most locations and the flow of product in this network:

• There are 2 suppliers (not shown on the map): 1 in China and 1 in India who supply the Primary DC in Rotterdam (yellow location icon, blue flow lines) with the 4 modeled products (2 phones and 2 tablets).
• The primary DC supplies the 8 country-level secondary DCs, which are the dark green flow lines to the locations with the blue icons.
• The 144 customers are supplied by their closest DC; these are the light green flow lines to the orange circle icons.

Demo Model – Inputs

In this model, the following tables are populated, most of which we will see a screenshot of further below. A reminder that it is helpful to only show Cyclo tables and fields using the Technology Filter at the top.

Facilities

This table contains the 2 suppliers, primary DC in Rotterdam, and 8 country-level secondary DCs. They are geocoded based on city and country data.

Products

The Products table contains the 4 products which are being modeled. To minimize safety stock, it is important to set a unit value for the products so that safety stock costs can be calculated and minimized.

Production Policies

These are not strictly required in this model, as the source of the products can also be deduced from the Transportation Policies table, but the table can be populated if desired. We see that the “_1” products are coming from the supplier in China and the “_2” products are supplied by the India supplier.

Inventory Policies

For each of the DC-product combinations, a record is specified in this table. Initially, the Stocking Site field is set to True for all, meaning the Primary DC and 8 secondary DCs can all hold safety stock for all 4 products. Note that they are not used in this model, but the Unit Value and Inventory Carrying Cost Percentage fields on this table can be used to override the global values set in the Products and Model Settings tables.

Transportation Policies

The following sets of transportation policies have been added:

• The suppliers use an ocean mode to ship their product to the Primary DC. The transport time from the India supplier is 25 days and from the China supplier 30 days.
• The Primary DC uses a truck mode to serve all country-level DCs. The transport time, which also includes processing time, varies between 1 and 4 days based on the distance.
• Each CZ is served by the DC closest to it and the transport time is 1 day for all these lanes.

Customer Order Profiles

There are 2 sets of demand specified in the Customer Order Profiles table:

• The orders with Order ID ending in _orig: these use normal and triangular distributions for the quantity field. The Status field of this set is set to Include and will by default be used. The first 4 records shown below are of this _orig set for customer CZ001.
• The orders with Order ID ending in _new: these also use normal and triangular distributions which have the same mean / mode as the corresponding _orig order, but with the variability (standard deviation; range between left and right) reduced by about 10% as compared to the _orig values. The Status field of this set is set to Exclude. This set will be included as part of a scenario testing out what the impact on the safety stock will be when demand variability is reduced. Records 5-8 in the screenshot below show these _new orders for CZ001:

Not shown in the above screenshot: but the Time Between Orders for all these records is set to 7 days, so we are modeling weekly demand.

Inventory Settings

In this model, we have left the target service level and service type at their defaults of 95% and Type 1. The target service level will be varied in several scenarios. Note that it is not used in this model, but you can use the Inventory Policies Advanced table to specify product-location specific target service levels, which will override this global value.

Model Settings

It is important to set an Inventory Carrying Cost Percentage in the Model Settings table to calculate safety stock holding costs. Here it is set to 10%. This global value can be overridden by specifying product-location specific values in the Inventory Policies table.

Demo Model – Scenarios

The following scenarios are included in the template model, from top to bottom:

• Six scenarios, “85pct TSL”, “90pct TSL”, etc., which use all the inputs as specified in the input tables as-is and only vary the target service level as follows: 85%, 90%, 95%, 97%, 98%, and 99%.
• “Less Demand Variability” tests the impact of having less variable demand. It contains 2 scenario items: 1 to exclude the set of demand records where the Order ID ends in _orig and 1 to include the set of demand records where the Order ID ends in _new.
• “Reduced Ocean LT” examines the effect of the transport lead-times from the India and China suppliers being reduced to 80% of the original lead-time.
• “No SS At Primary DC” asks what happens if the Primary DC in Rotterdam cannot hold safety stock and all safety stock needs to be held at the customer-facing country-level secondary DCs?

Demo Model – Outputs

Target Service Level Scenarios

First, we will have a look at the 6 target service level scenarios, for which the outputs in the Inventory Network Summary output table are shown in ascending order of service level:

As we expect, the higher the required service level, the more safety stock the network needs to hold, which also leads to increased safety stock holding costs. In the “MEIO – Cost vs Service” dashboard in the Analytics module, we can clearly see that as the service level is being pushed closer to 99%, the cost curve becomes steeper:

Other Scenarios

Now, we will compare the 95% target service level with the other scenarios that were run, which each also require a 95% service level. Starting with the Inventory Network Summary output table again:

Comparing each scenario with the 95pct TSL baseline scenario, from top to bottom:

• “Less Demand Variability” – in this scenario, the variability in demand is reduced by about 10% as compared to the “95pct TSL” scenario. This leads to a reduction in total cost and total safety stock by about the same percentage.
• “No SS At Primary DC” – in this scenario, all Safety Stock is held at the country-level DCs. When also holding at the Primary DC in the “95pct TSL” scenario, the demand propagated from the secondary DCs to the Primary DC results in a pooling effect where the variability in the demand is reduced (it “evens out”). When pushing all safety stock to the secondary DCs, the pooling effect is no longer there, and in total more safety stock needs to be held, which leads to higher costs. The screenshot after the next one also shows this in the Inventory Safety Stock Summary output table.
• “Reduced Ocean LT” – when the long ocean lead-times from the India and China suppliers are reduced to 80% of the original lead-time, we can hold less safety stock overall as we need to cover less lead-time. Compared to the “95pct TSL” scenario, the reduction in cost and safety stock is close to $300 and just over 5k units.

The “MEIO – Safety Stock at DCs” dashboard also shows the safety stock as a stacked column for these 4 scenarios, where the colors indicate the contribution of the total safety stock from each DC. Again, we see that the “Less Demand Variability” and “Reduced Ocean LT” scenarios have overall less safety stock across all DCs as compared to the “95pct TSL” scenario. In the “No SS At Primary DC” scenario, the large pink bucket that represents the safety stock at the primary DC in the other scenarios is not there anymore and instead the other 8 DCs each hold a lot more safety stock than they did in the “95pct TSL” scenario.

Lastly, we use the Inventory Safety Stock Summary output table to compare the safety stock for 2 secondary DCs and the primary DC for the “95pct TSL” and “No SS At Primary DC” scenarios:

1. In the “95pct TSL” scenario, the safety stock for phone_1 at the Primary DC covers 30 days of net replenishment time (the entire lead-time from the China Supplier to the Primary DC).
2. Still in the 95pct TSL scenario, the secondary DCs in Belgium and Italy only cover the lead-time from the Primary DC to these DCs, which are 2 and 3 days, respectively.
3. In the No SS At Primary DC scenario, the net replenishment time at the Primary DC is forced to be 0 as it is not allowed to hold any safety stock.
4. This means that the DCs in Belgium and Italy now need to cover 32 and 33 days of net replenishment time, respectively.
5. This leads to greatly increased safety stock at the secondary DCs, also at the other 6 not shown in this screenshot.

Summary

Cyclo brings advanced Multi Echelon Inventory Optimization capabilities into Cosmic Frog.

By optimizing service-time commitments and safety stock placement across the entire supply chain network, Cyclo helps organizations:

• Reduce inventory holding cost
• Improve service performance
• Increase supply chain resilience
• Better understand safety stock trade-offs
• Optimize network-wide safety stock positioning

Cyclo is especially valuable for organizations operating complex, multi-stage supply chains where local safety stock decisions can create unintended network-wide impacts.

Please do not hesitate to contact our support team on Support@optilogic.com in case of any questions of feedback.

Finding problems with any Cosmic Frog model’s data has just become easier with the release of the Integrity Checker. This tool scans all tables or a selected table in a model and flags any records with potential issues. Field level checks to ensure fields contain the right type of data or a valid value from a drop-down list are included, as are referential integrity checks to ensure the consistency and validity of data relationships across the model’s input tables.

In this documentation we will first cover the Integrity Checker tool’s scope, how to run it, and how to review its results. Next, we will compare the Integrity Checker to other Cosmic Frog data validation tools, and we will wrap up with several tips & tricks to help users make optimal use of the tool.

Integrity Checker Scope

The Integrity Checker extends cell validation and data entry helper capabilities to support users identify a range of issues relating to referential integrity and data types before running a model. The following types of data and referential integrity issues are being checked for when the Integrity Checker is run:

Here, we provide a high-level description for each of these 4 categories; in the appendix at the end of this help center article more details and examples for each type of check are given. From left to right:

1. Numeric: checks that the field contains a number within the expected valid range. Specific checks for this type of issue are:
2. Unit of Measure (UoM): checks that UoM fields contain valid values from the Units of Measure table Symbol column for any of the allowed Unit of Measure Types for that field.
3. Master table: these are referential integrity checks to ensure data relationships between input tables are consistent and valid.
4. Data Type: checks that the type of data that is entered into the field matches the data type of the field.

Running the Integrity Checker

The Integrity Checker can be accessed in two ways while in Cosmic Frog’s Data module: from the pane on the right-hand side that also contains Model Assistant and Scenario Errors or from the Grid drop-down menu. The latter is shown in the next screenshot:

1. We are in Cosmic Frog on the Optilogic platform (optilogic.app).
2. If you are not in the Data module yet, click on the Module Menu icon (the icon with 3 horizontal bars) and select “Data”.
3. From the Grid drop-down menu, user can choose from 2 options to run the Integrity Checker:
   1. Check all tables* in the model.
   2. Check only the selected table, which is the active table showing in the center of Cosmic Frog.

*Please note that in this first version of the Integrity Checker, the Inventory Policies and Inventory Policies Multi-Time Period tables are not included in any checks the Integrity Checker performs. All other tables are.

The second way to access the Integrity Checker is, as mentioned above, from the pane on the right-hand side in Cosmic Frog:

1. This pane on the right-hand side either shows the Model Assistant when the first of the 3 icons (the one with the check mark) is clicked, Scenario Errors when the second icon (with the exclamation mark) is clicked, or the Integrity Checker when the third icon (with the database picture) is clicked. Here the Integrity Checker icon has been clicked, which you can tell by the color of the icon: it is a darker blue than the other 2 icons.
2. When you run the Integrity Checker for the very first time on a model, 2 buttons are available here:
   1. Click on the top button to run the Integrity Checker on all tables in the model (except on the Inventory Policies and Inventory Policies Multi-Time Period tables).
   2. Click on the second button to run the Integrity Checker on the selected table, which is the active table showing in the center of Cosmic Frog, which would be the Products table here.

If the Integrity Checker has been run previously on a model, opening it again will show the previous results and gives user the option to re-run it by clicking on a “Rerun Check” button which we will see in screenshots further below.

After starting the Integrity Checker in one of the 2 ways described above, a message indicating it is starting will appear in the Integrity Checker pane on the right-hand side:

Integrity Checker Results

While the Integrity Checker is running, the status of the run will be continuously updated, while results will be added underneath as checks on individual tables complete. Only tables which have errors in them will be listed in the results.

1. In the top part of the Integrity Checker pane, the status of the run is listed. Here, the run is still in progress (“Running”). In parentheses it tells the user if this is a run on all tables, like it is here, or on an individual table (the “selected table” option). If it is on an individual table, the name of the table is listed in the parentheses. A summary of the results so far is included in this part:
   1. The time and date when the Integrity Checker run started.
   2. The total number of errors found so far.
   3. The number of tables that have errors in them so far.
2. For each table with any errors in it, a card appears in the bottom part of the Integrity Checker. It lists the table name, the number of errors found, and the time and date when this table was last checked. So far, the Integrity Checker found errors in the Products table (1 error) and the Transportation Policies table (3 errors).
3. To stop the Integrity Checker run before it has completed, user can click on the Cancel Check button.

Once the Integrity Checker run is finished, its status changes to Completed:

1. Now the status of the Integrity Checker has changed to Completed after the run has finished. The red exclamation mark icon in front of the status indicates that errors were found by the Integrity Checker. When an Integrity Checker run does not find any errors, this icon will be a green checkmark instead.
2. Besides the errors in the Products and Transportation Policies tables, there is a third table with errors, the Production Constraints table.
3. Users can type into the Search box to filter the list of tables with errors in them down to those containing the search text in their name.
4. Sorting the list of tables with errors in them can be done too: click on the icon with horizontal bars and choose 1 of 3 sorting options:
   1. Default – this will sort the tables in the same order as they are in the Input Tables list.
   2. A-Z – this will sort the tables alphabetically; in ascending order when selected for the first time, in descending order if clicked on a second time.
   3. Checked Time – this will sort tables in the order of when their checks completed from first to last; clicking on this option again will sort in the reverse order from last to first completed check.
5. After addressing the errors identified by an Integrity Checker run, user may want to double-check they have mitigated all the issues. They can then run the Integrity Checker again by clicking on the Rerun Check button.

Users can see the errors identified by the Integrity Checker by clicking on one of the table cards which will open the table and the Integrity Checker Errors table beneath it:

1. User clicked on the Transportation Policies table card in the bottom part of the Integrity Checker where it was listed that this table contains 3 errors, this opens the Transportation Policies table.
2. At the bottom another table named Integrity Checker Errors is opened as well. By default, it is expanded; it can be collapsed by clicking on the down caret button. The button then changes to an up caret one, which will expand the table when clicked on.
3. For each of the errors identified by the Integrity Checker this table contains 1 record describing the error using the following fields:
   1. Relevant Technology: this lists the technology/technologies the error applies to. If you are using the model to run a technology not listed here, you can ignore the error, as the technology does not use the column that has the error. As a reminder, the 5 technologies available in Cosmic Frog and their names are:
      1. Neo – network
      2. Throg – simulation
      3. Hopper – transportation
      4. Dendro – inventory
      5. Triad – Greenfield
   2. Type: what sort of error was found; this can for example be one of the following (for a full list of the error types see the high-level overview in the Integrity Checker Scope section above and for more details and examples see the Appendix – Integrity Checker Scope Details further below):
      1. Required Field – the field is required to have a value, it cannot be empty.
      2. Invalid Enum – the value the column should have can be one of a finite set of options, as listed in the field’s drop-down list when double-clicking in it.
      3. Invalid Reference – the value in the field should exist in another Cosmic Frog Model Elements input table, or as a group or named filter.
      4. Non Negative – the value in the field cannot be negative, it should be greater than or equal to 0.
      5. Positive Numeric – the value in the field cannot be negative or 0, it should be greater than or equal to 1.
   3. Description: explains the type of error and in case the value of the field should be one of a finite number of options (e.g. there is a drop-down list in the column), it lists the valid values.
   4. Column: the column (/field) the error was found in.
   5. Row Count: the number of rows (/records) in the table that have this error in this column.
4. Let us walk through the first error listed for the Transportation Policies table:
   1. The error only applies to the Neo technology (network optimization): if user is planning to run a network optimization on this model, then the error should be addressed. If they are planning to run another technology on this model, they can ignore this error.
   2. The error type is Invalid Enum – the value should be one of a finite number of options but is something different currently.
   3. The description column explains the error in more detail. In this screenshot, the whole description is not visible due to the width of the Description column, but hovering over shows the full text: “Value must be one of: To Optimize, By Ratio (Auto Scale), By Ratio (No Scale)”. In other words, there are 3 valid values for this field, and the current value is not one of these.
   4. Column indicates which column in the Transportation Policies table the error was found in, this is the Optimization Policy column in this case.
   5. The Row Count for this error is 1 – there is 1 record in the transportation policies table that has this error where the Optimization Policy field contains an invalid value.

Clicking on a record in the Integrity Checker Errors table will filter the table above (here the Transportation Policies table) down to the record(s) with that error:

1. We have clicked on the first record in the Integrity Checker Errors table underneath the Transportation Policies table. As covered in the previous screenshot, this error applies to the Neo technology only, and it says that 1 record in the Transportation Policies table has an invalid value in the Optimization Policy column.
2. By clicking on the record in the Integrity Checker Errors table, the Transportation Policies table is filtered for the record(s) with that error. User can recognize this by the label at the right top of the table that the “Integrity Checker” filter is applied, which has a red database icon associated with it. User can take this filter off by clicking on the x on the right of the filter name.
3. We see that indeed 1 of 9,342 rows in this table has been filtered out.
4. In this record, the Optimization Policy field is set to “Not to optimize” which is not one of the three valid values for this field.

User can go through each record in the Integrity Checker Errors table at the bottom and filter out the associated records with the errors in the table above to review the errors and possibly fix them. In the next screenshot, user has moved onto the second record in the Integrity Checker Errors table:

1. User has clicked on the second record in the Integrity Checker Errors table. This error applies to 3 technologies (Neo, Throg, and Dendro) and it is an Invalid Reference type of error in the Destination Name column found in 1 record in the Transportation Policies table. The description explains that the value of this field has to exist in one of 3 master tables (Customers, Facilities, Destinations) or corresponding groups or filters.
2. We see again that an Integrity Checker filter is applied and that this results in 1 record being filtered out in the Transportation Policies table.
3. The Destination Name of this record is set to Ports. Checking the master tables, there are no Customers, Facilities or Suppliers named Ports present in the model. Neither are there any named filters named Ports present in these master tables. Lastly, there also are no groups with a group name of Ports present in the Groups table. Therefore, Ports is not a valid destination for a transportation policy.

We will look at one more error, the one that was found on the Products table:

1. In the Integrity Checker results, user clicks on the Products card.
2. This opens the Products table and the Integrity Checker Errors table beneath it.
3. There is 1 error listed here, which user has clicked on to filter the Products table down to the 1 record that has this Non Negative error in the Unit Price column. The description explains that the value for this field should be larger than or equal to 0. This error applies to the Neo, Throg, and Dendro technologies.
4. Looking at the filtered out record with the error, the Unit Price field contains a value of -1500, which is an invalid value for this column.

Finally, the following screenshot shows what it looks like when the Integrity Checker was run on an individual table and in the case no errors are found:

1. The Integrity Checker was run on an individual table by selecting the “Selected Table” option. The name of the table, Replenishment Policies here, is listed in the parentheses.
2. There were no errors found, which can be seen from:
   1. The green checkmark icon as opposed to the red exclamation mark icon when errors have been found.
   2. Total errors and tables with errors both are 0.
   3. The text “No Validation Errors Found” in the lower part of the Integrity Checker.

Comparison with other Cosmic Frog Data Validation Tools

There are additional tools in Cosmic Frog which can help with finding problems in the model’s data and overall construction, the table below gives an overview of how these tools compare to each other to help users choose the most suitable one for their situation:

Tips & Tricks

Please take note of the following so you can make optimal use of the Integrity Checker capabilities:

1. You do not have to wait for the Integrity Checker tool to complete to start looking at its results. Once a table card has appeared in the results indicating a table has errors, you can click on the card and start reviewing the errors in that table. You can also go to other parts of Cosmic Frog or even out of the model and back in at a later time while the Integrity Checker is running, and the results will be available to you once you get back into the Data module of the model you ran the Integrity Checker on.
2. If the Integrity Checker has been run on a model previously, the next time you open the model, the most recent results of the Integrity Checker are still available to you. Depending on what was run previously (all tables or selected table) and in the case of selected table, which table, running the Integrity Checker again will behave as follows:
   1. If the Integrity Checker was run on all tables previously, then clicking on the “Rerun Check” button will run the Integrity Checker on all tables again. If you want to run the Integrity Checker on 1 selected table, you will need to do it from the Grid drop-down menu.
   2. If the Integrity Checker was run on the selected table previously, then there will be a “Rerun Check” button if the same table is the currently active table and the check will be run on that table again. If a different table is the currently active table, the button will read “Run Check” and clicking on it will run the Integrity Checker on the 1 selected table. If you want to run the Integrity Checker on all tables, you will need to do it from the Grid drop-down menu.
3. The Integrity Checker Errors table has a lot of the same options for configuration as the other Cosmic Frog input and output tables have, such as dragging and dropping the columns to change their order, clicking on column headers to sort by that column, resizing columns, etc. In addition, user can choose certain configuration actions from a context menu:

1. 1. To open the context menu for configuring the table and its columns, click on the icon with 3 dots next to the column you want to configure.
   2. The context menu comes up: select your desired configuration action from the list.
2. Progress of the Integrity Checker and optionally cancelling it, can be done from within the Integrity Checker pane on the right-hand side in Cosmic Frog as we have seen above. In addition, user can also check progress of or cancel Integrity Checker runs, through the Run Manager application on the Optilogic platform:

1. 1. User has opened the Run Manager application.
   2. Two jobs are showing here, both are of Integrity Checker runs in Cosmic Frog:
      1. This integrity checker job has been submitted and is still running. If needed it can be cancelled by right-clicking on it and selecting “Cancel Job”.
      2. This integrity checker job has finished running successfully as indicated by its “done” status.

Appendix – Integrity Checker Scope Details

We saw the next diagram further above in the Integrity Checker Scope section. Here we will expand on each of these categories and provide examples.

From left to right:

1. Numeric: checks that the field contains a number within the expected valid range. Specific checks for this type of issue are:
   1. Non-negative: the field needs to have a value greater than or equal to 0. Example: the Unit Price field on the Products table will be flagged if it contains a numeric value <0.
   2. Positive numeric: the fields need to have a value greater than 0. Example: the Lot Size field on the Processes table will be flagged if it has a value <1.
   3. Percentage: the field needs to have a value between 0 and 100 as it represents a percentage. Example: the Service Band Percentage field on the Greenfield Service Bands table will be flagged if it has a value > 100 or < 0.
   4. Risk scores: a risk score field needs to have a value between 0 and 10. Example: the Risk Score field on the Risk Band Definitions table will be flagged if it has a value <0 or >10.
   5. Latitude: any field that contains a latitude of a location needs to have a value between -90 and 90. Example: the Latitude field on the Customers table will be flagged if it has a value <-90 or >90.
   6. Longitude: any field that contains a longitude of a location needs to have a value between -90 and 90. Example: the Longitude field on the Facilities table will be flagged if it has a value <-90 or >90.
2. Unit of Measure (UoM): checks that UoM fields contain valid values from the Units of Measure table Symbol column for any of the allowed Unit of Measure Types for that field.
   1. Example: valid unit of measure types for the Unit Cost UOM field on the Customer Fulfillment Policies table are: Quantity, Volume, and Weight. So, if a non-existing Unit of Measure or one of a different type is entered here, the field is flagged. If the field contains “MI”, which is a valid Distance type unit of measure, it will be flagged, because it can only accept unit of measure types of Quantity (e.g. EA for each), Volume (e.g. CFT for cubic foot), and Weight (e.g. LB for pound).
   2. Please note that UoM fields can be left blank, in which case it will use the primary UoM of one of the allowed UoM types for the field. Primary UoMs are defined on the Model Settings table. If in the previous example the Unit Cost UoM field on the Customer Fulfillment Policies table is left blank, the Primary Quantity UoM value on the Model Settings table is used (can also see this by hovering over the column name, which shows a tooltip containing a “Default Value” among other details of the field). By default, the Primary Quantity UoM on the Model Settings table is set to EA; users can update this to another valid UoM of Type = Quantity listed on the Units of Measure table.
3. Master table: these are referential integrity checks to ensure data relationships between input tables are consistent and valid. The entities of the supply chain being modeled are entered into the Model Elements input tables (i.e. Master tables) – Customers, Facilities, Suppliers, Products, Periods, and Organizations, and several other model-type specific tables (Processes, Work Centers, Work Resources, Bills of Materials, Transportation Modes, Transportation Assets, and Shipments). In addition to the single entities specified in these tables, they can be grouped together either through the Groups table or by using Named Filters. When members of a group behave the same way in (parts of) the supply chain (e.g. same cost structure, same O-D pairs, etc.) the group’s name / named filter’s name can be used in the other input tables which define the supply chain’s behavior in terms of costs, demand, policies, constraints, etc. instead of having to define a record for each individual member of the group. These master table integrity checks ensure that for fields that reference a master supply chain element the value of that element exists in its master table(s) or as a corresponding group or named filter.
   1. Example: the Product Name field on the Transportation Policies table will be flagged by the Integrity Checker if the value in the field does not match the Product Name of a record on the Products table (“basic referential”), does not match the name of a saved filter on the Products table (“table filter”), and does not match the Group Name of 1 or multiple records on the Groups table (“groups”).
4. Data Type: checks that the type of data that is entered into the field matches the data type of the field. Specific checks for this type of issue are:
   1. Double, integer, string, date/time, time: if the data in the field is not of the specified data type it will be flagged. Example: the Optimization Policy Value field on the Customer Fulfillment Policies table will be flagged if it contains a string (e.g. “ten”) instead of a numeric value (type double) like for example 20.5 or 60.
   2. Required: the field cannot be blank. Example: the Product Name field on the Production Policies table needs to be populated, it will be flagged if it is left blank.
   3. Enums: the field needs to contain a value from a finite list of valid values (i.e. there is a drop-down list available when double-clicking in the field). Example: there are only 2 valid values for the Status field on the Warehousing Policies table – Include and Exclude (leaving blank is fine too, it will then default to use Include); entering for example “Consider” into the field will be flagged as an error.

Note that the numeric and data type checks sound similar, but they are different: a value in a field can pass the data type check (e.g. a double field contains the value -2000), but not the numeric check (a latitude field can only contain values between -90 and 90, so -2000 would be invalid).

We hope you will find the Integrity Checker to be a helpful additional tool to facilitate your model building in Cosmic Frog! For any questions, please contact Optilogic support on support@optilogic.com.

Once you have run a model, you can visualize your results using the Analytics module. A dashboard in the Analytics module is a collection of visualizations. Visualizations can take on many forms, such as charts, tables or maps.

Accessing the Analytics Module

To access the Analytics module:

1. Click on the hamburger icon to open the Modules drop-down list.
2. Click on Analytics in the list which will open the Analytics module.

Once in the Analytics module, the left-hand side panel looks as follows:

1. There is a set of default dashboards included in every new Cosmic Frog model. We will see some examples of these next. Their names indicate the technology they apply to:
   
   1. "Optimization..." dashboards are specific for Neo (network optimization) solves.
   2. "Greenfield..." dashboards are specific to Triad (Greenfield) solves.
   3. "CTS..." dashboards are cost to serve dashboards specific for Neo solves.
   4. The "Sensitivity at Scale" dashboard analyzes outputs of scenarios run using the Sensitivity at Scale Scenarios option in Cosmic Frog, which can use any of the technologies.
   5. "Transportation..." dashboards are specific for Hopper (transportation optimization) solves.
2. At the top there is an Analytics drop-down menu which we will see the details of a little further below.
3. To quickly find the dashboard of interest, users can use the search textbox. Dashboards with the typed search text in their name will be filtered out.
4. The dashboards can be sorted either by Default, which is the order in which they were added, or by Name. The latter sorts them alphabetically in ascending order (A to Z) and when clicked again the sort is reversed (Z to A).
5. This left-hand side panel can be collapsed by clicking on the double caret icon. Clicking the icon while collapsed will expand the panel.

Default Dashboards

When opening a dashboard it is shown in the central part of Cosmic Frog. This is the default Optimization Scenario Comparison dashboard shown for the Global Supply Chain Strategy model, which highlights some common analytics and metrics:

Many dashboards are designed to be interacted with through a set of filters, like for example the Optimization Transportation Flows one (also shown for the Global Supply Chain Strategy model):

In the screenshot directly above, the dashboard is shown for all products in the model, which includes raw materials and finished goods. Filtering for just the finished goods changes the shown chart on this dashboard as follows:

We can hover over visualization elements to get more information, which will be shown in a tooltip. Here, we show the information for one of the facilities, Princeton Factory, in a chart named Facility Geographic Risk Metrics, which is part of the Optimization Facility Risk Summary dashboard. This is again in the Global Supply Chain Strategy model:

Analytics (Context) Menu

The Analytics drop-down menu at the top of the module contains the following options:

1. New Dashboard - creates a new empty dashboard where users can add and configure their own visualizations.
2. Duplicate - makes a copy of the currently selected dashboard. Users can for example use a copy as a starting point for their own modifications and additions.
3. Rename - change the name of a dashboard.
4. Copy Name - copies the name of the dashboard to the Clipboard.
5. Delete - removes the dashboard; users will be prompted to confirm the removal.

The context menu that comes up when right-clicking on a dashboard in the list has all the same options, except for the New Dashboard one:

Creating a New Dashboard

After you click on New Dashboard in the Analytics menu, the central part of Cosmic Frog will look as follows:

1. First, give the dashboard a name.
2. Optionally, add a description for the dashboard, which will be shown underneath the name in smaller font.
3. To add a visualization, e.g. a graph, chart, table, etc., click on the + Visualization button.
4. You can also add a textbox by clicking on the caret icon here to bring up the Text Box option.
5. Use the buttons at the bottom right to expand or maximize this form.
6. To close this form without creating a new dashboard, click on the cross icon at the top right.

Creating a New Visualization

Choosing the Data Source

After clicking on the + Visualization button, first we need to choose the source data we will use for the visualization:

1. The database ID of the model we are working in is displayed, this is just for the user's information.
2. Data for visualizations can be pulled from the tables and views and present in the model database; functions can be used too to pre-process data used. We will use a table here.
3. In the Search textbox type part of the table, view, or function name to quickly find it.
4. Select the table you want to use by clicking on it. We have chosen the optimization facility summary, a Neo output table.
5. A preview of the data in the table can be brought up by clicking on the magnifying class icon.
6. Once a table, view or function has been selected, click on Select Data to continue to the next step.

Configuring Chart Data

The form now looks similar to the following screenshot, where on the left-hand side the visualization can be configured and on the right-hand side the chart will be shown as it is being built:

1. At the top left, users can swap between configuring the data for the visualization and the visualization settings. First, we will stay in the Data section.
2. The name of the table or view we are using to build the visualization is repeated here. Click on the icon with the 3 vertical dots on the right to bring up the option to refresh the data to ensure we are working with and previewing the latest.
3. You can bring up all options for the visualization type by clicking on the caret icon. We are using a column chart.
4. The list of fields available in our data source is here on the left:
   
   1. The list can be filtered down by typing into the search textbox to only show fields containing the search text in their field name.
   2. Additional fields can be added; these can be calculated fields using 1 or more fields in the chosen data source or field(s) from another table or view within the same model database can be brought in.
5. To configure the visualization, drag fields from the list on the left to the different areas here; these can differ based on the chart type chosen.
   
   1. Labels refer to the labels on the visualization axes and consequently the groups by which you want to aggregate your values.
   2. Values represent the data you want to be presented in the visualization. Typically, values are aggregated representations of your data (e.g. sum, average, etc.).​​
   3. Categories allow for additional grouping.
   4. Fixed Lines lets users add a field that will be drawn as a superimposed line on the chart, independent of the other values displayed. The line represents an aggregated value (summed, averaged, etc.) over all data shown in the graph.
   5. Filters allow users to adjust inclusion and exclusion criteria while viewing the chart.
6. In the area on the right the chart will become visible as it is being built.

After dragging the fields we want on top of the Label, Values, and Category areas, our visualization configuration area looks as follows:

1. We are using Scenario Name as the Label, the summed Total Outbound Quantity as the Values, and Facility Name as the Category. This was configured by dragging and dropping the fields from the list on the left (not shown) on top of the desired area.
2. We can see what the chart will look like on the right-hand side.
3. Clicking on an added field here will bring up a Field Settings form where display names, aggregation, etc. can be adjusted. We will see this in the next screenshot.
4. Instead of dragging fields on top of the Values box(es), users can also opt to calculate the values to be used in the chart. Click on the F(x) button to bring up the Calculated Fields form.

Configuring Individual Fields

Clicking on a field in any of the configuration areas (bullet 3 above) brings up the Field Settings form:

1. The displayed name of the field is shown and can be edited here by clicking on the pencil icon.
2. For numerical fields, field settings can be specified for three different categories: General, Formatting, and Conditional Formatting. Click on the area you want to review/adjust to see all options. For fields with other data types the options change here accordingly.
3. Once happy with the field settings, click on Update Field to persist any changes made.

The following screenshot shows an example of using conditional formatting in a grid visualization, where the background color for values less than 2M is orange and over 2M green:

Visualization Editing Options

While the chart is being configured, its current state is shown on the right-hand side where several additional settings and options are available to the user:

1. Give the chart a title. By default it is set to the data source name.
2. Optionally, add a description for the chart.
3. One or multiple filters can be added to show a subset of the data in the chart. Note that filters can be added to the dashboard as well, which are applied to all visualizations on the dashboard. Using dashboard-level filters is preferred when wanting to sync multiple visualizations on the same dashboard.
4. Options from left to right are:
   
   1. Statistical Functions - these include: time series forecast, linear regression, and detect outliers.
   2. View Data - clicking on this shows the visualization's underlying data in grid format. Clicking on it again will return to the chart view.
   3. Undo - revert the last change.
   4. Redo - make the last change again.
   5. Cancel - close the visualization without saving changes.
   6. Save - save all changes and close the visualization editor.

Configuring Visualization Settings

The chart configuration options available to the user under the Settings tab are shown in the next 2 screenshots; these specify what is shown on the chart and the formatting of the different chart items:

‍

Dashboard Editing Options

Once you are happy with the visualization, click on the Save checkmark icon to save it and close the editor for this visualization. This will bring you back to the dashboard:

1. You can drag the blue points in the middle of the right and lower edges and the bottom right corner to resize the added visualization.
2. To go back to editing the visualization, click on the pencil icon.
3. More options are available under the icon with 3 vertical dots:
   
   1. Edit - this is the same as using the pencil icon under the previous button and will open the visualization editor again.
   2. Copy - copies the visualization and its configuration to the clipboard. It can now be pasted into the same dashboard or another using a dashboard-level option (under the icon with 3 vertical dots, see bullet 4 below).
   3. Duplicates - creates a copy of the visualization in the same dashboard.
   4. Rename - change the name of the visualization.
   5. Delete - remove the visualization. Note that the user will not be prompted to confirm this before the visualization is deleted.
4. At the top dashboard-level editing options become available once at least 1 visualization has been added. These are from left to right:
   
   1. Undo - revert the most recent change to the dashboard.
   2. Redo - perform the last change again.
   3. + Visualization - add another visualization or text box to the dasshboard.
   4. Options under the icon with 3 vertical dots are:
      
      1. Refresh - load all underlying data for the visualizations to ensure the latest is being used.
      2. Paste - if a visualization has been copied, it can be pasted into a dashboard (the same one or a different one) using this option.
      3. Auto layout - a toggle that can be turned on where the visualizations on the dashboard will be automatically sized and fitted together.
      4. Export - export the dashboard. Format options are: image, PowerPoint, PDF, and Excel.
   5. Cancel - stop editing the dashboard and do not save changes since the last time the dashboard was saved.
   6. Save - save all changes and stop editing the dashboard.
5. Add one or multiple dashboard-level filters which can selectively apply to all or a subset of the visualizations included in the dashboard simultaneously. You can choose either a Dashboard or Date filter; see the next 2 screenshots.

Adding Dashboard Filters

When you choose a Dashboard Filter, you are first prompted to choose your data source (a table, view or function) in the same way as selecting the source data for a visualization. After selecting your source, the Dashboard Filter form is shown:

1. We have chosen the same optimization facility summary table as our source for filtering the visualizations on the dashboard.
2. You can edit the name of the filter by clicking on the pencil icon. By default it has the same name as the selected Displayed Field, see next bullet.
3. From the drop-down, select the Field will the connected visualization(s) will be filtered by.
4. If the Display Field should be different from the Field (previous bullet), select it here from the drop-down.
5. Update any Settings for Selection, Data Filters, Read Only Filter, and Hidden as desired.
6. For each individual visualization on the dashboard, click on the Connect button or anywhere inside its card if you want the filter to apply to it. Here, the visualization on the left ("DC throughput...") has been connected to the filter already, whereas the one on the right ("Facility Costs...") has not been connected yet.
7. Click on the Create Filter button to add the configured filter to the dashboard.
8. If you want to cancel out of creating the filter, click on the cross icon at the right top of the form.

Creating a Date Filter works as follows:

1. Optionally, give the filter a name.
2. In the Date Filter drop-down list, choose the date range to filter the connected visualization(s) by.
3. Configure if the filter should be read only and/or hidden.
4. Click on the Connect button or anywhere inside the card of the visualization(s) you want this filter to apply to.
5. Click on the Create Filter button to add the configured filter to the dashboard.
6. If you want to cancel out of creating the filter, click on the cross icon at the right top of the form.

Note that after a Date Filter has been added to the dashboard, users can still switch between different timeframes when using the filter; this is not fixed at the time of Date Filter configuration.

After a filter has been created, it is accessible in the top part of the dashboard, underneath the dashboard's description. Here we have added a filter for scenario name:

1. Click on the caret to use the filter.
2. Use the checkboxes to enable/disable all or individual scenarios.
3. Click on the Apply button for the filter to take effect.

Editing Dashboards

​We can customize existing dashboards to fit our needs. Click on the icon with 3 vertical dots to bring up the options to Edit, Refresh, and Export (Image, PowerPoint, PDF, or Excel) the current dashboard. If previously a visualization was copied to the Clipboard, a Paste option will be available here too:

Please see the sections above on adding and configuring visualizations and dashboards which apply here in the same way.

Tips & Tricks

If bars are not showing in a chart this is likely due to the first column having no value or its value being 0. To resolve:

1. For charts where multiple fields are used in the Values area: reorder these, so that the first field results in a non-0 value for the first column in the chart. See also first screenshot below.
2. For charts where 1 field is used in the Values area: apply a sort to the Category. See also second screenshot below.

1. Since there is only 1 field used here for Values, re-ordering fields in case no bars are showing in the chart is not an option.
2. Instead, we can sort the Category field. Click on it to open the Field Settings form.
3. The Field Settings form for StopSite (used as the Category) has been opened. Here:
   
   1. Change the Sorting from None to either Ascending or Descending.
   2. Choose the field to Sort By; often sorting by the same field as the Label field makes sense, which is done here (routename).
4. Click on Update Field to persist the sort changes.

As always, please reach out to our Support team at support@optilogic.com in case of any questions or feedback.

To learn all about dashboards and visualizations within Cosmic Frog, please refer to the Getting Started with Analytics help center article, which contains the latest information.

Watch the video to learn how to build dashboards to analyze scenarios and tell the stories behind your Cosmic Frog models. You can also refer to the Getting Started with Analytics help center article, which contains the latest information as of July 2026 in text + screenshot format.

Cosmic Frog users can now perform additional quick analyses on their supply chain models’ input and output data through Cosmic Frog’s new grid features. This functionality enables users to easily apply different types of grouping and aggregation to their data, while also allowing users to view their data in a pivoted format. Think for example of the following use cases:

• Perform a quick check of the total demand / shipment quantity specified in the customer demand / customer orders / shipments input tables, in total or for example by product or customer (region).
• Get the average distance and / or time for certain types of flow and / or by mode from the flow summary output tables.
• Count the number of times inventory is below or above a certain level.
• Find the minimum and / or maximum utilization of facilities, transportation assets, or work centers.

In this documentation we will cover how grids can be configured to use these new features, show several additional examples, and conclude with a few pointers for effective use of these features.

How to Access the New Grid Features

These new grid features can be accessed from the “Columns” section on the side bar on the right-hand side of input and output tables while in the Data module of Cosmic Frog:

1. We are on the Optimization Flow Summary output table, a network optimization (Neo) output table.
2. Click on “Columns” on the right-hand side of the table.
3. This opens the panel on which row grouping, aggregation, and pivot grids can be configured.
4. There are 3 modes available to the user:
   1. Row grouping – when the Pivot Mode dial is off and only the Row Groups part of the Columns configuration panel is used.
   2. Aggregated table mode – when the Pivot Mode dial is off and both the Row Groups and ∑ Values areas of the Columns configuration panel are being used.
   3. Pivot mode – when the Pivot Mode dial is on (moved to the right) and the Row Groups, ∑ Values, and Column Labels areas of the Columns configuration panel are being used.

Alternatively, users can also start grouping and subsequently aggregating by right clicking on the column names in the table grid:

1. Right click on the name of the column to be used to group by, in this case on the ScenarioName column.
2. Select “Group by ScenarioName” from the context menu.

We will first cover Row Grouping, then Aggregated Table Mode, and finally Pivot Mode.

Row Grouping

Using the row grouping functionality allows users to select 1 or multiple columns of an input or output table by which all records in the table will be grouped. These groups of records can be collapsed and expanded as desired to review the data. In the following screenshot the row grouping feature is used to compare the sources of a certain finished good in a particular period for 1 scenario:

1. We are on the Optimization Flow Summary table, which is an optimization (Neo) output table.
2. The table has filters applied to the scenario name field, the departing period name field, and the product name field. This filters the table for 1 specific scenario, 1 specific period (YEAR1), and 1 specific finished good (FG_SWI).
3. The Origin Name field is used as the column to group the rows by: right click on the field and choose the “Group by OriginName” option OR click on Columns on the right-hand side of the table and configure the OriginName field as the Row Group.
4. Now all records are grouped by each Origin Name that exists in the filtered data. By default, the groups are collapsed like this one shown for DC_2. In parenthesis the number of records that are grouped together (i.e. that have DC_2 as the origin) is listed, 11 in this case.
5. For DC_1 and DC_3 the records (9 for DC_1 and 3 for DC_3) have been expanded as the user wanted to compare the flows of FG_SWI in YEAR1 for these 2 distribution centers.

When clicking on Columns on the right hand-side of the table to open the row grouping / aggregated table / pivot grid configuration pane shows the configuration for this row grouping:

1. Pivot Mode is left turned off.
2. The Origin Name field is used as the Row Group.
3. The ∑ Values area is left blank as no aggregation of data is needed when just grouping by a row.
4. These 4 fields are being shown in the table, besides the grouped Origin Name: Destination Name, Product Name, Mode Name, and Flow Quantity.

The above example showed grouping the rows by 1 column, this next example shows the same table, but now the rows are grouped by 3 columns. Note that you can change the order of the Row Groups by clicking on a column header and dragging it up or down.

The table then looks as follows:

The number in parenthesis indicates how many unique values there are for the next row group:

• The (expanded) scenario Sc2_Consider_ new_ Lines has an 8 in parenthesis: there are 8 unique origin names in this scenario.
• DC_2 is expanded and it has a 5 in parenthesis, indicating that 5 unique products are shipped from this DC in this scenario.
• FG_SWI is expanded and it has 51 in parenthesis meaning there are 51 records in this table for this scenario - origin - product combination.

Aggregated Table Mode

Once a table is grouped by one or more fields, a next step can be to aggregate one or multiple columns by this/these grouped field(s). When this is done, we call this aggregated table mode. Different types of aggregation are available to the user, which will be discussed in this section.

When configuring the grid through the configuration panel that comes up when clicking on Columns on the right-hand side of input & output tables, several options are available to help users find field names quickly and turn multiple on/off simultaneously:

1. Clicking on this checkbox will enable or disable all fields that are displayed in the list below simultaneously.
2. Type part of a field name in the search box to filter for fields containing the text to quickly find field(s) of interest.

To configure the grid, fields can be dragged and dropped:

1. Click on the icon with 12 little dots (in between the checkbox and the field name) and hold the mouse down to drag the field into 1 of the configuration boxes below. In the screenshot above the Scenario Name field is being dragged.
2. Drop the field into the Row Groups area if the field should be used for aggregating the rows in the grid. In the case of dropping the Scenario Name field here it means that whichever other fields we enable, they will be aggregated by scenario.
3. Drop the field into the ∑ Values area if the field should be aggregated by the row groups. Multiple fields can be dragged into this area.

Alternatively, instead of dragging and dropping, users can also right-click on the field(s) of interest to add them to the configuration areas. This can be done both in the list with column names at the top of the configuration window as shown in the following screenshot, but also on the column names in the grid itself (which we have seen an example of in the “How to Access the New Grid Features” section above):

In the screenshot above (taken with Pivot Mode on which is why the Column Labels area is also visible), the user right-clicked on the Flow Volume field and now they can choose to add it to the Row Groups area (“Group by FlowVolume”), to the ∑ Values area (“Add FlowVolume to values”), or to the Column Labels area (“Add FlowVolume to labels”).

The next screenshot shows the result of a configured aggregated table grid:

1. Still on the Optimization Flow Summary output table and in grid mode, the user has added Scenario Name to the Row Groups configuration area.
2. The Flow Volume field was added to the ∑ Values area, by default it will be summed as it is a numeric field (see below).
3. As no other fields are used for this aggregated table grid, the result is a table with 2 columns. The first column is for Scenario Name, the row groups field. Note that for each scenario the number of rows that were aggregated is listed in parentheses.
4. The second field in the table is for the summed Flow Volume. So, we are looking at the total flow volume by scenario here.

When adding numeric fields to the ∑ Values area, the following aggregation options are available to the user:

1. Click on the icon with 12 little dots to bring up the aggregation options drop-down list.
2. The options are:
   1. Avg – calculates the straight average of the field (sum of all values divided by the number of values).
   2. Sum – calculates the sum of all values.
   3. Max – finds the maximum value and shows this.
   4. Min – finds the minimum value and shows this.
   5. Count (not shown in screenshot) – counts the number of values.
   6. First (not shown in screenshot) – the lowest numeric value found for numeric fields (i.e. same as Min) and the first value found for text fields when sorted alphabetically
   7. Last (not shown in screenshot) – the highest numeric value found for numeric fields (i.e. the same as Max) and the last value found for text fields when sorted alphabetically.

For non-numeric fields, only the last 3 options are available as aggregations:

1. Here we look at the Mode Name field as the example.
2. As this is a text field, only count, first and last are available as the aggregation options.

When adding an aggregation field through right-clicking on a field name in the grid, it looks as follows. The user right-clicked on a numerical field, Transportation Cost, here:

When filters are applied to the table, these are still applied when the table is being grouped by rows, aggregated, or pivoted:

1. The user has clicked on Filters in the right-hand side bar of the Optimization Flow Summary output table to bring up the Filters configuration form.
2. A filter is set up to only show flows to customers (the filter is: FlowType field Contains “customer”).
3. We can see at the right top of the table grid that a filter is active and which field(s) it is applied to.
4. This changes the aggregated grid as the number of rows is now reduced as compared to the previous screenshot of summed flow volume by scenario name. The Baseline now shows 580 rows vs 690 before.
5. The summed flow volume now represents the flow volume to all customers and for Baseline this amounts to 954,885. When not filtering for customer flows, the total Baseline flow volume was over 6.3M, see the earlier screenshot above.

It was mentioned above that the number in parentheses after the scenario name represents the number of rows that the aggregation was applied to. We can expand this by clicking on the greater than (>) icon to view the individual rows that make up the aggregation:

1. In this aggregated grid, the user has clicked on the greater than icon (>) to the left of the Baseline scenario name to expand the 131 rows that make up the aggregation. Clicking on this icon again, which has turned into an upside-down caret icon, will collapse the rows again.
2. It is again an aggregated grid of summed flow volume by scenario on the Optimization Flow Summary output table, but additional fields are shown: Origin Name, Destination Name, and Product Name (note that in the table grid in this screenshot, product name is not visible, you need to scroll right to see it).
3. The table has a filter applied to the Product Name field.
4. At the left top of the table, it is also indicated how many rows of the total are being shown in the grid.
5. The top rows of the 131 that make up the rows for the Baseline aggregation can be seen here.

Next is an aggregated table mode example where more than 1 Row Group is used. Here, the Flow Quantity on the Optimization Flow Summary table is summed by scenario, origin, and product:

The resulting table:

1. For this scenario, Sc2_Consider_ New_LINES, the total flow is just under 6.8M.
2. Of this total, 374k and 434k come from DC_1 and DC_ 2, respectively.
3. The split over the 5 finished goods of the total 434k flow out of DC_2 is outlined in this green box.

Pivot Mode

When users turn on pivot mode, an extra configuration area named Column Labels becomes available in addition to the Row Groups and ∑ Values areas:

1. The user has turned Pivot Mode on. We are still looking at an example on the Optimization Flow Summary output table.
2. In addition to Scenario Name as the row group and summing Flow Volume still, now the Product Name has been added to the Column Labels area of the pivot grid configuration form.
3. This results in all products that are present in the Optimization Flow Summary output table to be put across the grid as columns. (Note that not all products are shown in the screenshot, we need to scroll right to see the others).
4. A filter is applied to the Flow Type field, which is the same as we have seen above: to filter out only flows to customers.
5. We see that in the Baseline the total volume of flow to customers for product FG_FET is 236,646 and for product FG_MOZ it is 198,544.
6. In Grouped Row Mode, Aggregated Table Mode and Pivot Mode, fields can be removed from the configuration areas by clicking on the x icon on the right-hand side of the field name. Alternatively, users can right-click on the field name in the list and choose “Un-Group by ScenarioName”, etc.

Another example to show the total volumes of different flow types, filtered for finished goods, by scenario is shown in the next screenshot:

1. Flow Type has now been added as the Column Label field.
2. The 2 Flow Types that are present in the Optimization Flow Summary output table are listed across as the columns: Replenishment and CustomerFulfillment.
3. The table has a filter applied to Product Name, which is to filter out Finished Goods (products with a Product Name that starts with FG_; not shown in the screenshot).
4. In the “No demand yr5” scenario, we see that the total replenishment flow volume of finished goods is 130,891 and the total flow volume of finished goods to customers (the Customer Fulfillment flow type) is the same amount: 130,891.

Additional Examples

So far, we have only looked at using the new grid features on the Optimization Flow Summary output table. Here, we will show some additional examples on different input and output tables.

In this first additional example, a pivot grid is configured to show the total production quantity for each facility by scenario:

1. We are on the Optimization Product Summary output table, another network optimization (neo) output table.
2. Pivot Mode is turned on.
3. The configuration of the pivot grid is as follows:
   1. We again have set up Scenario Name to be the row group field.
   2. Summed production quantity will be shown as the values in the grid.
   3. The Facility Name field is used for Column Labels.

In the next example, we will show how to configure a pivot grid to do a quick check on the shipment quantities: how much the backhaul vs linehaul quantity is and how much of each is set to Include vs Exclude:

1. We are on the Shipments input table, a table used by the transportation optimization (Hopper) and simulation (Throg) engines.
2. Pivot Mode is turned on.
3. The pivot grid is configured as follows:
   1. The Notes field, which for each shipment record contains either “Backhaul” or “Linehaul” is used as the row group field.
   2. The summed Quantity is shown as the values in the grid.
   3. The Status field, which is set to either Include or Exclude, is used for column labels.
4. For Backhaul we see that 32,047 units are included in the input data and 3,654 units are set to Exclude.

In the following 2 examples, we are doing some quick analysis on the Simulation Inventory On Hand Report, a simulation (Throg) output table containing granular details on the inventory levels by location and product over time. In the first of these 2 examples, we want to see the average inventory by location and product for a specific scenario:

1. We are on the Simulation Inventory On Hand Report simulation output table.
2. Pivot Mode is turned on and the configuration is as follows:
   1. Facility Name is used as the row group.
   2. Inventory On Hand Quantity is used for values and the type of aggregation is to calculate the average.
   3. Product Name is used as column labels.
3. A filter (not shown) is applied to the Scenario Name field, so the values shown in the pivot grid are those for 1 specific scenario, the Baseline in this case.
4. We see that there are 2,101 records for inventory on hand at the DC_VA location. The average inventory quantity for Product_4 at this location is 778 units, for Product_1 449 units, and for Product_3 314 units.

In the next example, we want to see how often products stock out at the different facilities in the Baseline scenario:

1. The pivot grid configuration is the same as in the previous example, except that now instead of summing the inventory on hand quantity, we are counting the number of occurrences.
2. An additional filter is applied (not shown) which filters for the inventory on hand quantity being equal to 0. So, the count results in how often the inventory on hand is 0 for the specific location-product combination, in the Baseline scenario, as that filter is still applied too.
3. At DC_AZ, we see that Product_4 stocks out 11 times during the simulation horizon in the Baseline scenario, Product_1 117 times and Product_3 186 times.

The last 2 examples in this section show 2 different views of Greenfield (Triad) outputs. The first example shows the average transport distance and time by scenario:

1. The table we are on is the Optimization Greenfield Flow Summary table, an output table of the Greenfield (Triad) engine.
2. Pivot mode is not turned on, so we are in aggregated table mode.
3. Scenario Name is added as the row group and the averages of the Transport Distance and Transport Time fields are used for the values.
4. Between the “7 Optimal Facilities Paris Fixed” and “Cost Optimized” scenarios, we see a reduction in both average transport distance and average transport time.

Lastly, we want to look, by scenario, how much of the quantity delivered to customers falls in the 300 miles, 500 miles, and 750 miles service bands:

1. We are still on the Optimization Greenfield Flow Summary output table and have turned Pivot Mode on now.
2. As Row Group we have selected Scenario Name again, values shown are summed flow quantities and Service Band Names will be across the grid as columns.
3. We see that the “Cost Optimized” and “Cost Optimized Increased Demand” scenarios have the highest amounts of delivered quantity in the shortest service band of 300 miles.

Final Notes

Please take note of following to make working with Row Grouping, Aggregated Table Grids and Pivot Grids as effective as possible:

• A quick way to remove columns from a grouped or aggregated grid: while grouping and/or aggregating columns, if Pivot Mode is enabled but no Column Labels are specified, all columns that are not currently used for grouping or aggregation will be hidden.
• When a table has been grouped by any rows, has been aggregated, or a pivot grid has been configured on it, these persist. When switching view to another table, going into another Cosmic Frog module or out of a model and coming back to it later, the configured grid will still be the same as how it was last configured.
• As mentioned above, if a filter is applied, that applies to grouped tables, aggregated tables, and pivot grids too. Columns that are filtered out will show values of 0 in this case and are not entirely removed from the grid. For example: if there are 2 products in the model, 1 product is filtered out, and Product Name is used as Column Labels in a Pivot Grid, then the 2 products will be shown as the columns and the values of the product that is not included in the filter are all set to 0. This does not mean that all the values for this product would be 0 if the product was not filtered out.
• The same field cannot be used multiple times in a pivot grid.
• To get back to normal table mode, users need to remove the fields from the Row Groups, ∑ Values, and Column Labels areas by clicking on the x icons or right-clicking on the fields in the list and choose the option to remove the field from the area it is used in.
• The export to Excel/CSV features are not available when in grouped table, aggregated table, or pivot grid mode, but users can use the “Copy with group headers” functionality to copy-paste the grid into for example Excel:

1. Put the cursor in a cell of the pivot grid, then use Ctrl + A to select the whole pivot grid.
2. Right-click on the pivot grid and select the “Copy with Group Headers” option from the menu. When pasting into Excel, it will look similar to following screenshot:

In this quick start guide we will walk through how you can build a DataStar macro for repeatable Cosmic Frog model building, where data needs to be refreshed periodically, through chatting with Ada.

When using Ada to have the Modeler Agent create a model, it is a non-deterministic process where you may not get the same results every time. Once you are happy with the model you have built using Ada, you want to be able to repeat those steps every time in a reliable, performant, deterministic fashion. That is the value of being able to persist the process in DataStar.

It is helpful to be familiar with the contents of the following Help Center articles prior to diving into this quick start:

• Getting Started with Ada & Agentic AI
• Next Generation Optilogic Platform Overview

Quick Start Steps

This quick start guide uses a historical shipments file that was also used in the Importing a CSV File quick start guide. In addition, we will create a second data connection for a basic costs file and import that one into the Project Sandbox too. We then use the data in those 2 files to populate tables of an initially empty Cosmic Frog model with the aim to run a Neo solve. Finally, the steps to populate this model are automatically captured in a DataStar macro to create a repeatable model build workflow. In summary the steps are:

1. Create 2 data connections in DataStar, for the 2 CSV files contained in this zip-file. The 2 files contain historical shipment and basic cost data.
2. Create a new project in DataStar, add a macro to it, and import the data from the 2 connections in bullet 1 into the project sandbox.
3. Create a new empty Cosmic Frog model.
4. Chat with Ada in the next generation Optilogic platform to populate the Cosmic Frog model and simultaneously create a DataStar macro capturing the model build steps.
5. Review the Cosmic Frog model and DataStar macro.
6. Iterate on any model changes as needed, while keeping the DataStar macro updated.

Data and Initial Steps

We will cover what is contained in the 2 CSV files and steps 1-3 in this section.

Data

The next 2 screenshots show the structure of the data in the 2 CSV files used in this quick start.

Of the Historical_Shipments.csv file, the first 5 of a total of 42,656 records are shown. The Ship Dates range from May 2024 through August 2025:

The next 2 screenshots show all data contained in the Basic_Costs.csv file:

Initial Steps

1. Create a new project in DataStar, giving it your desired name; we used “DS Macro by Ada to Build CF Model”.
2. Refer to the DataStar Quick Start: Importing a CSV File article on how to create Data Connections and Import tasks for the 2 CSV files. Once the macro with the 2 Import tasks is set up, run it:

1. Refer to the Creating a New Model section of the Creating and Managing Models article on how to create a new empty Cosmic Frog model. You can use your preferred model name; in this example we used “CF Model by DS Macro by Ada".

Chat with Ada

Now, we move on to chatting with Ada in the next generation Optilogic platform at https://ai.optilogic.app. Here, we will walk-through an initial prompt and the back and forth that follows. Note that you can get different responses and clarifying questions from Ada, even with the same starting data and initial prompt.

We first connect the DataStar project and empty Cosmic Frog model in the Databases drop-down selector, and then submit our prompt:

1. We leave the interaction stye at the default of Scout. For an explanation of the options here, please see the Create Your First Prompt section in the Getting Started with Ada & Agentic AI documentation.
2. From the Databases drop-down, we connect the empty Cosmic Frog model we just created, “CF Model by DS Macro by Ada”, and the DataStar project named “DS Macro by Ada to Build CF Model”, which contains the data of the imported CSV files.
3. Since our aim is to build a Cosmic Frog model, we choose the ModelerAgent from the agents drop-down list. See the section linked under the first bullet to learn more about when to use which agent.
4. The prompt we are submitting reads: “Using the 2 tables in the DataStar project, populate the tables in the connected Cosmic Frog model with the goal to run a NEO solve which can be used to optimize my outbound distribution assignments based on production and transportation costs, aligning each customer to their optimal distribution center. Note to:
   • 1) Use only data from July 2024 through June 2025.
   • 2) Add and geocode a Factory in Raleigh, NC, USA, where the 2 products are manufactured.
   • 3) Persist the steps in DataStar in a new macro called “Model Build”.”
5. Once the prompt has been entered, hit the Enter key or click on the submit icon to submit it to Ada.

Ada comes back with three consecutive clarifying questions, 1 on model configuration decisions and 2 to approve running the DataStar macro and a Neo solve on the Cosmic Frog model. You can see the questions and the user’s responses in this screenshot:

Ada’s response is then as follows:

So, this achieved what we set out to do in the prompt. We did not yet run the Neo solve as we first want to examine the Cosmic Frog model and DataStar macro.

Review Cosmic Frog Model and DataStar Macro

In DataStar, we see that in addition to the macro that imports the data from the 2 CSV files, there is now a Model Build macro present too. Note that you may need to refresh your browser to see the new macro in case the project was still open from before. You can click on any task to select it and inspect its configuration which comes up on the right-hand side.

Opening the model in Cosmic Frog, we see that the expected tables are populated. Here, the Facilities table is shown with the 7 DCs and 1 (geocoded) Factory, as we requested:

All tables look good, except:

1. The Model Settings table has model start and end date set to January 1, 2025, and December 31, 2025, respectively.
2. The Unit Cost values for the Factory-DC lanes on the Transportation Policies table look to be of the right order of magnitude, however, we are unsure how the distances used to calculate these costs (unit cost = per mile cost * distance / average shipment size) were derived:

Iterate on Model and Macro

To understand the distance calculation and correct the model horizon, we continue our conversation with Ada:

As a result of the last prompt Ada updates the build_transportationpolicies Run SQL task in the Model Build macro, which we can see by opening its SQL Script:

In addition, she adds 2 tasks to the Model Build macro to take care of setting the model start and end date in the Model Settings table:

Double-checking the Cosmic Frog model to ensure the updated macro was run and results in the desired changes, we can see that the Unit Costs on the Factory-DC lanes have increased by 17% and that the Model Settings table now has Model Start Date and Model End Date set correctly.

Now we have created a repeatable, deterministic workflow in DataStar to build a basic Neo model from the 2 input files, which may be refreshed with newer data regularly.

Example Prompts

To get an idea of the types of interactions you can have with Ada while working on DataStar projects, here are some example prompts to get you started:

1. What does the "Profile Data” macro in the connected DataStar project do?
2. Explain the logic of how transportation policies are created in the "Build Policies Tables” macro in the connected DataStar project.
3. What macros are present in the connected DataStar project? Summarize what each macro does.
4. When was the last successful run of the "Clean raw data” macro in the connected DataStar project? How long did it take and what resource size was used?
5. How often was each macro in the connected DataStar project run and how often did each fail?
6. Update all Export tasks in the "Model Build” macro in the connected DataStar project so that the Destination Connection is changed to the connected "Global Supply Chain Strategy” Cosmic Frog model, while keeping mappings and destination tables unchanged.
7. Add a task or multiple tasks to the "EMEA Greenfield” macro in the connected DataStar project. The task(s) need to create unique facility candidates from the 3 “shipment_...” tables.
8. Run the “Cleanse Data” macro in the connected DataStar project. If it completes successfully, also run the “Model Build” macro.
9. In the connected Cosmic Frog model, copy all records in the Customer Demand table and paste them back in as a second set with following changes: 1) Status = Exclude, 2) Notes = Next year demand, 3) increase the quantity by 10% for all A_ finished goods, by 5% for all B_ finished goods, and by 2% for all C_ finished goods. Create a “Second Demand Set” macro in the connected DataStar project that performs these same changes.

Helpful Resources

• The Getting Started with Ada & Agentic AI documentation contains the following sections on prompting that are relevant here too:
  • Best Practices
  • Tips & Tricks
  • Current Limitations & Known Behaviors
• Learn more about DataStar
• Learn more about Cosmic Frog

As always, please do not hesitate to reach out to our Support team via support@optilogic.com in case of questions or feedback.

Please feel free to download the Cosmic Frog Python Library PDF file. Please note that this library requires Python 3.11.

You can also reference the video shown below that covers an overview on scripting within Cosmic Frog.

Thank you for using the most powerful supply chain design software in the galaxy (I mean, as far as we know).

To see the highlights of the software please watch the following video.

Overview

The Air Express Freight Costing utility solves the challenge of pricing air express freight shipments when carrier rate data is complex and varies by service level, distance, and weight. Rather than manually looking up rates in carrier tariff tables, this workflow automates the entire process using FedEx Express Freight standard list rates. The utility expects a lanes-to-cost table containing shipment details including origin, destination, distance, weight, and desired service level. After running the utility, users receive a fully costed table with calculated transportation costs.

The Air Express Freight Costing Utility is available on the Resource Library, from which you can download it or copy it to your Optilogic account. Learn more about the Resource Library in this How to use the Resource Library help center article.

What's Included

Sample Data

• Sample lanes_to_cost CSV file (5,000 lanes across the US)

System Utility

• Air Express Freight Costing utility accessible via the "Run AI Agent" task in DataStar
• Built-in FedEx Express Freight rate tables (automatically loaded by the utility)

How To Use

The steps to use this utility are as follows. These are illustrated with screenshots below.

1. Prepare your input data:
   • Create a lanes_to_cost table with all required columns (see Input Requirements)
   • Ensure distances are calculated in miles
   • Assign appropriate service levels to each shipment
   • Set the destination_rural flag correctly for Alaska/Hawaii destinations, see also the Tips & Notes section
2. Upload your data to a database in DataStar
   
   • Upload the file to your Optilogic account
   • Create a data connection to it in DataStar
   • Import the data into the project sandbox by using an Import task
3. Run the utility:
   • Open the "Run AI Agent" task in DataStar
   • Select "Air Express Freight Costing" from the available utilities
   • Configure the parameters:
     • Database: Enter your database name
     • Schema: Select the schema containing your table
     • Lanes Table: Select your lanes_to_cost table
     • Output Table: Specify the output table name
     • Keep Working Tables: Toggle on to retain intermediate tables for debugging
     • Verbose: Toggle on for detailed logging
4. Review the output table containing costed lanes

Screenshots of the steps where the project from the Resource Library is used (Copy to Account option), which creates the DataStar project including macro shown below in the user's account:

Input Requirements

Lanes to Cost Table (Required)

Key Constraints:

• Each combination of (service_level, origin_id, destination_id, shipment_weight) must be unique
• No NULL values allowed in any required column
• Service level values are case-sensitive and must match exactly
• Weights must be positive numbers in pounds
• Distances must be in miles

Output Description

The utility produces an output table containing all lanes from the input with the following columns populated:

Zone Determination

Zones are determined automatically based on the following priority:

Special Zones (for Alaska/Hawaii):

1. Destination AK/HI + rural=True: Zone "11 (To AK rural)"
2. Destination AK/HI + rural=False: Zone "9-10 (To AK/HI metro)"
3. Origin AK/HI: Zone "13-16 (From AK/HI)"

Standard Distance-Based Zones:

Cost Calculation

Costs are calculated using the following formula:

• ‍base_charge = shipment_weight x price_per_lb
• final_cost = MAX(base_charge, minimum_charge)

Effective Weight: If the shipment weight is below the minimum weight for a service/zone combination, the utility uses the minimum weight band's rate but calculates the charge based on the actual shipment weight.

Service Levels

Tips & Notes

• The workflow is fully deterministic - given the same inputs, it will always produce the same outputs.
• Original input tables are never modified. The utility creates working copies for all processing.
• The FedEx rate tables are built into the utility and are automatically loaded. You do not need to provide rate data.
• For Alaska and Hawaii destinations, the destination_rural flag is important. Set it to True for rural Alaska locations, False for metro areas. This determines whether the "11 (To AK rural)" or "9-10 (To AK/HI metro)" zone rates apply.
• Service level values must match exactly (case-sensitive). Use the exact strings: "1Day Freight", "2Day Freight", "3Day Freight", or "First Overnight Freight".
• The minimum charge floor ensures that very light shipments still meet the carrier's minimum pricing requirements.
• If a shipment weight is below the minimum weight threshold for a service/zone, the rate from the lowest weight band is used, but the cost is still calculated using the actual shipment weight (not the minimum weight).
• This utility currently supports US domestic air express freight shipments only. The rate structure includes special handling for Alaska and Hawaii.

Other Helpful Resources

• Learn more about Cosmic Frog
• Learn more about DataStar
• An overview of Optilogic's AI Agents and Utilities
• The Full Truckload Costing Utility, also available from within DataStar
• The Less-Than-Truckload Costing Utility, also available from within DataStar

‍

Overview

The Model Output Insights Agent helps users investigate and analyze Cosmic Frog model outputs by turning analytical questions into structured, data-backed strategic reports. It breaks down complex questions into a step-by-step exploration plan, executes targeted queries, synthesizes findings, and produces a professional report - complete with visualizations and actionable recommendations.

This documentation describes how this specific agent works and can be configured. Please see the “AI Agents: Architecture and Components” Help Center article if you are interested in understanding how the Optilogic AI Agents work at a detailed level.

Why It's Useful

Extracting meaningful insights from large databases typically requires exploring and analyzing many output tables which can take a lot of time and effort. The Model Output Insights Agent streamlines the process, helping users get to the insights quicker than ever before.

• Enhances productivity by automating complex research, analysis, and reporting tasks.
• Delivers high-quality, data-backed executive reports suitable for decision-makers.
• Adaptable to a wide range of analytical domains, from business strategy to technical investigations.

Key Capabilities

Structured Exploration

• Operates using a to-do list approach, breaking down analytical questions into discrete, manageable tasks.
• Progresses methodically by selecting and addressing one task at a time, ensuring thoroughness and clarity.

Deep Analytical Reasoning

• Utilizes the Analyzer skill (see table below) to query databases, analyze data, and synthesize findings.
• Provides evidence-based insights and actionable recommendations.

Executive Reporting

• When sufficient findings are gathered, it invokes the Report Builder skill (see table below) to generate comprehensive, professional-style executive reports.
• Reports include sections such as Executive Summary, Situation Assessment, Problem Statement, Analytical Framework, Methodology, Key Findings, Scenario Analysis, Data Summary, Insights & Recommendations, Validation, Strategic Implications, and Next Steps.

Iterative and Adaptive

• Addresses one to-do per turn, allowing for focused analysis and adaptability based on interim findings.
• Can conclude early if enough information is obtained, optimizing efficiency.

Main skills the Model Output Insights Agent uses:

Supporting capabilities:

How To Use It

The agent can be accessed through the Run AI Agent task in DataStar. Once a Run AI Agent task is added to the macro, first the Model Output Insights Agent needs to be selected from the list of available agents and utilities in the "Select Utility" section:

Next, the inputs and settings for the task can be specified in the Configure Utility, Run Configuration, and Notes sections:

1. Cosmic Frog Model Name - The model that the user wants to analyze.
2. Analysis Questions - This is where the user asks the agent what they would like to know from the model outputs. It can be as simple as "Give me cost and flow comparison between Scenario A and Scenario B", or more involved/a longer list of questions.‍
3. Knowledge Folder (optional) - Provide additional context for the agent to understand business background, modeling strategy, or even a request for a certain report style. The accepted file formats are md, csv, and txt. To use these files, we recommend creating a folder in the Explorer application, uploading the files to it, and entering the Folder Path as the Knowledge Folder input of the Run AI Agent Task. The screenshot below shows how to get a Folder Path.‍
4. Report File Name - This field is populated with "exploration_report" by default, but users can specify their own name for the report file.‍
5. Output Directory - Specify the folder name where the report and charts will be saved (default = Model Output Insights Agent). The system assumes that this is a folder name under My Files, so you do not need a full folder path here. This is different from what is needed for Knowledge Folder. For example, if the full folder path is /projects/My Files/Model Output Insights Agent_Report/ABC, only "Model Output Insights Agent_Report/ABC" is needed in this box
6. The run Configuration Section contains the following settings, which can optionally be set/adjusted:
   
   • Tags: Enter the tags for this task for easy filtering in the Run Manager application.
   • Timeout: The time allowed for the task to run until being stopped.
   • Resource Size: Different resource sizes offer different memory (RAM in Gb) and number of CPU cores to handle various task complexities. This only impacts ability to load the work into memory. The recommendation is to start with the default setting, monitor memory usage in the Run Manager application > Job Usage, and scale up if needed. The key principle is that a bigger resource does not always result in faster agent response time.
7. In the Notes section users can optionally add information about the task - especially useful when working in teams.

This next screenshot shows how to get a Folder Path while in the Explorer application: 1) right-click on the folder in the Explorer, 2) hover over Copy in the context menu, and 3) click on Folder Path:

After the run, a report in both markdown (.md) and pdf (.pdf) format and charts (if any) are created and can be found in the Explorer with the specified file name and folder. Once clicked, the file is opened in the Lightning Editor application for review.

Note that currently the charts are only included in the markdown file as a file name. Users can look for the charts in the Charts folder in the targeted output directory.

Other Helpful Notes

• If the Report File Name already exists in the Report Directory, a numbered suffix will be added to avoid overwriting the existing file - e.g., exploration_report (1).
• Runtime for the agent varies based on the amount of data to analyze and the complexity of the question(s). Expect at least 10 minutes of runtime.
• Just like many other DataStar tasks, it is possible to run multiple tasks in parallel with the Model Output Insights Agent.
• Additional info on the run can be found in the Task Logs tab underneath the Macro Canvas. This includes steps that the agent takes, tools it calls, as well as a work summary. The AI Response sections are typically the most useful as they explain the exploration plan, the work it has done, and the results after exploration. This is generally a response to the user, while all others are more about internal processes.

• The following screenshot shows part of a report instructions file, which can be placed in the Knowledge Folder specified in a Run AI Agent task that uses the Model Output Insights Agent. It contains info on target audience for the report, expected report length and tone. If you would like to review it and optionally use as a starting point for your own usage with this Agent, you can download it here. After downloading, please rename the .txt extension to .md. You can then upload it to your Optilogic account using the Explorer application and then view it in the Lightning Editor application.

Other Helpful Resources

• Learn more about Cosmic Frog
• Learn more about DataStar
• An overview of Optilogic's AI Agents and Utilities
• The Data Cleansing AI Agent
• The Data Profiler AI Agent
• The Modeler AI Agent

Overview

The Data Cleansing Agent is one of Ada’s AI-powered assistants. It helps users profile, clean, and standardize their database data without writing code. Users describe what they want in plain English -- such as "find and fix postal code issues in the customers table" or "standardize date formats in the orders table to ISO" -- and the agent autonomously discovers issues, creates safe working copies of the data, applies the appropriate fixes, and verifies the results. The agent handles common supply chain data problems including mixed date formats, inconsistent country codes, Excel-corrupted postal codes, missing values, outliers, and messy text fields. It expects a connected database with one or more tables as input. The output is a set of cleaned copies of their tables in the database which users can immediately use for Cosmic Frog model building, reporting, or further analysis, while the original data is preserved untouched for comparison or rollback.

This documentation describes how this specific agent works and can be configured, including walking through multiple examples. Please see the “AI Agents: Architecture and Components” Help Center article if you are interested in understanding how the Optilogic AI Agents work at a detailed level.

Why It's Useful

Cleaning and standardizing data for supply chain modeling typically requires significant manual effort -- writing SQL queries, inspecting column values, fixing formatting issues one at a time, and verifying results. The Data Cleansing Agent streamlines this process by turning a single natural language prompt into a full profiling, cleaning, and verification workflow.

1. Enhances productivity by automating repetitive data cleaning tasks that would otherwise require custom SQL or manual inspection.
2. Reduces errors by using purpose-built tools that handle edge cases (e.g., Excel scientific notation corruption, leading-zero preservation in postal codes) that are easy to miss in manual cleanup.
3. Preserves data integrity by always working on copies -- original tables are never modified, so there's no risk of data loss.
4. Adapts to any database schema -- no fixed column name requirements. The agent discovers the structure automatically and applies the right tools.

What's Included

Key Capabilities:

1. Database Exploration -- Discovers tables and schemas, inspects sample values and value frequencies, and searches for specific values across columns.
2. Date Standardization -- Detects mixed date formats (including named months and partial dates) and converts them to ISO, US, European, or other custom formats. Handles ambiguous dates like '01/09/2024' (Jan 9 vs. Sep 1) via a configurable DMY/MDY interpretation policy and reports the inferred order back to the user.
3. Location Standardization -- Standardizes country names/codes to ISO 3166 (alpha-2, alpha-3, or full name), cleans city names, and applies smart title casing to addresses.
4. Postal Code Repair -- Repairs Excel-corrupted postal codes (scientific notation), restores leading zeros, removes placeholder values (N/A, XXXXX, etc.), cleans formatting, extracts postal codes from address strings, and validates against real postal code databases.
5. String Normalization -- Trims whitespace, standardizes casing, removes extra spaces, and handles punctuation and unicode cleanup.
6. Unit Conversion -- Converts measurement units (e.g., pounds to kilograms, inches to centimeters) using a reference table.
7. Missing Data Handling -- Fills missing values using strategies such as constant, mean, median, mode, forward fill, or backward fill. Supports grouped fills (e.g., median by customer segment).
8. Outlier Detection -- Detects outliers using IQR, Z-Score, or Modified Z-Score methods. Can handle outliers by nullifying, capping, replacing with statistics, or removing rows.
9. Type Casting -- Converts column data types (INTEGER, NUMERIC, TEXT, BOOLEAN, DATE, TIMESTAMP, TIMESTAMPTZ) with configurable error handling (skip / null / strict).
10. Custom SQL -- Executes any SQL statement for operations not covered by the specialized tools, such as creating views, computed columns, or complex joins.
11. Deduplication (via specialized sub-agent) -- Finds and resolves duplicate records. Supports exact matching, fuzzy matching, cross-table matching, and transaction-row deduplication. Creates golden-key mappings on a master table and propagates them to all referencing transaction tables.
12. Referential Integrity -- Surfaces primary-key duplicates/nulls and foreign-key orphan rows, presents realistic repair options (null the reference, delete orphans, insert stub parents, etc.), and applies the chosen fix on clean_* copies only after the user confirms. Reuses the Data Profiler's findings when a recent profiler run exists; otherwise inspects the schema directly.
13. Report Generation -- Produces a markdown or HTML report summarizing analysis or cleanup work, dispatched to a dedicated report-writer sub-agent that chooses the right format based on the user's framing.
14. Value Replacement -- Replaces specific values in a column (e.g., 'Cancelled' -> 'Canceled', 'N/A' -> NULL) for one or many columns in a batch. Useful for collapsing inconsistent boolean encodings (Y/N vs. Yes/No vs. 1/0) and bulk sentinel-to-NULL conversion.

Tools:

‍

How To Use It

The agent can be accessed on the next generation Optilogic platform by chatting with Ada and through the Run AI Agent task in DataStar. Both ways will be explained, via Ada first, then the DataStar workflow, followed by an overview of the main differences between the 2 methods.

Using the Data Cleansing Agent through Chat with Ada

It is recommended to be somewhat familiar with Ada before diving into this content. Please see the Getting Started with Ada & Agentic AI article, and in particular its How to Use Ada section.

Once logged into the next-generation Optilogic platform at https://ai.optilogic.app, you can start chatting with Ada leveraging the Data Cleansing Agent right away from the central part of the Home page.

1. If unsure how to start, or if you are just exploring, you can use one of the example prompts at the top to get going.
2. Underneath the prompt textbox, we can (from left to right):
   
   1. Select the interaction Style to use. These behave differently in how verbose the agent's answers will be and how often user confirmation/feedback will be sought before proceeding.
      
   2. Connect to Cosmic Frog models, DataStar projects, and Postgres databases. The prompt can refer to these; the agent will create clean_* copies of any tables it modifies.
   3. Choose the Data Cleanser Agent from the agent selector.
3. Type your question/task into the prompt textbox.
4. Click on the submit button at the right bottom of hte prompt box.

Regarding how to write good prompts, please note that the general Best Practices, Tips & Tricks, and Current Limitations and Known Behaviors included in the Getting Started with Ada documentation also apply to the Data Cleansing Agent.

After submitting a prompt, the Data Cleansing Agent will start processing and formulating a response:

1. The full prompt is shown at the top of the conversation.
2. Underneath the prompt, a status line shows what Ada is doing currently. To see each status update, expand this section by clicking on the caret icon to the left. Clicking on the Status Updates, Tool Calls, or Knowledge tabs shows progressively more detail.
3. If you want to stop Ada while she is still working on a response (say you realized your prompt is incorrect/incomplete or you have not connected the right database(s)), you can click the Stop button at the right bottom in the prompt box.

The Data Cleansing Agent may ask for feedback before proceeding — for example, when:

• A date column contains ambiguous values like '01/09/2024' (Jan 9 vs. Sep 1) and the agent wants to confirm DMY vs MDY interpretation.
• Sentinel values are detected and the agent wants confirmation before nulling them.
• Duplicate records are found and the agent wants confirmation on the merge strategy.
• Foreign-key orphans are found and the agent wants to confirm the repair option (null the reference, delete orphans, etc.).

1. First, Ada explains why she needs some feedback and/or confirmation to continue.
2. Next, some things Ada noticed while working on the prompt are noted in the lighter texbox. It gives users additional information to help make their decisions on how to proceed.
3. The feedback required to continue is then listed. Often this takes the form of multiple options: the user can just click on the option they want to go with.
4. In case none of the options suggested by Ada are suitable, the user can type how they want to proceed for that item in the textbox.
5. Once all feedback items have been addressed, click on the Send Response button for Ada to continue.
6. Click on the Stop Agent option in case continuing does not make sense.

When Ada finishes, the final response is presented:

1. The original prompt is listed at the top of the conversation.
2. The status line now shows how long the response took. To see full details, expand it.
3. Any clarifying questions Ada asked along the way and the answers given are shown — click the caret to expand them.
4. This is the final response where Ada summarizes what she did — which tables were modified, how many rows were affected, and where the cleaned data lives.
5. The user can continue the conversation by typing any follow-up questions/tasks and submitting them. It is recommended to start a new conversation if switching to an unrelated task, a different agent, different connected databases, or setting a different interaction style.

For completeness, the cleaned data shows up in the connected database as clean_* table copies — for example, clean_customers, clean_orders — with the originals preserved untouched for comparison or rollback:

Using the Data Cleansing Agent within DataStar

In DataStar, the Data Cleansing Agent is accessed by using a Run AI Agent task, see also the screenshots below. The key inputs are:

• Database -- Select the database to perform data cleansing on. All database types are supported (Cosmic Frog, DataStar, or Postgres).
• Task Description -- Describe what you want the agent to do. This is a free-text field (up to 10,000 characters) where you write your request in natural language. Be as specific as possible about tables, columns, and desired outcomes.

The Task Description field includes placeholder examples to help you get started:

• List all tables and analyze their data quality
• Standardize date formats in the orders table to ISO
• Find and fix postal code issues in the customers table
• Normalize country codes to ISO alpha-2 format

Optionally, users can:

• Enable Verbose Output (toggle to "Detailed") to see the full list of available tools and detailed execution information. Default is "Concise".
• Point the Agent to a Knowledge Folder. Any .md and .txt files placed here will be read by the agent and used as additional context to perform the task. Think of column descriptions, known data conversions, etc.

Not shown in the screenshots above, there is also a Run Configuration section, where users can add Tags to facilitate finding job runs, set a Timeout for the task, and set the Resource Size to use. Note that for most Run AI Agent tasks, the Resource Size will need to be set to XS or higher.

Suggested workflow:

1. Start with a profiling prompt to understand your data quality issues (e.g., "List all tables and analyze their data quality").
2. Review the agent's findings to understand what needs to be fixed. This information can be found in the Task Log, see the section "Reading the Task Log" below for more details.
3. Run a transformation prompt targeting the specific issues found (e.g., "Standardize date formats in the orders table to ISO and fix postal code issues in the customers table").
4. Review the summary the agent provides, which is the Agent Response section in the Task Log -- it reports what was changed, how many rows were affected, and any remaining issues.
5. Query the clean_* tables in the database to verify the results. The original tables remain untouched.

After the run, the agent produces a structured summary of everything it did, including metrics on rows affected, issues found, and issues fixed; see the next section where this Job Log is described in more detail. The cleaned data is persisted as clean_* tables in the database (e.g., clean_customers, clean_shipments).

Data Cleansing Agent Usage: Chat UI vs DataStar

There are a few differences to keep in mind when running the Data Cleansing Agent either through chatting with Ada or from within DataStar:

1. Chatting with Ada is conversational and interactive. It supports clarification questions, mid-run feedback, follow-up prompts in the same conversation, and on-the-fly database connection changes. Best for exploration, one-off cleanup, and tasks where the cleansing strategy isn't fully decided up front.
2. DataStar is batch and repeatable. It runs as a Run AI Agent task inside a Macro, ideal for cleanup that needs to be re-run on a schedule or as part of a larger pipeline. Mid-run feedback is not available — the prompt has to be self-contained, and any clarifications surface in the Task Log only after the task finishes.
3. Both produce the same artifacts: clean_* table copies in the connected database, and optionally a markdown or HTML report if requested.

Recommendation: Use the chat UI to develop and refine a prompt, then transfer the working prompt into a DataStar Run AI Agent task once you want the workflow to become repeatable.

Reading the Task Log

After a run completes, the Task Log provides a detailed trace of every step the agent took. Understanding the log structure helps users verify what happened and troubleshoot if needed. The log follows a consistent structure from start to finish.

Header

Every log begins with a banner showing the database name and the exact prompt that was submitted.

Connection & Setup

The agent validates the database connection and initializes itself with its full set of tools. If Verbose Output is set to "Detailed", the log also prints the system prompt and tool list at this stage.

Planning Phase

For non-trivial tasks, the agent creates a strategic execution plan before taking action. This appears as a PlanningSkill tool call, followed by an AI Response box containing a structured plan with numbered steps, an objective, approach, and skill mapping. The plan gives users visibility into the agent's intended approach before it begins working.

Tool Calls and Thinking

The bulk of the log shows the agent calling its specialized tools one at a time. Each tool call appears in a bordered box showing the tool name. Between tool calls, the agent's reasoning is shown in Thinking boxes -- explaining what it learned from the previous tool, what it plans to do next, and why. These thinking sections are among the most useful parts of the log for understanding the agent's decision-making.

The agent may call many tools in sequence depending on the complexity of the task. Profiling-only prompts typically involve discovery tools (schema, missing data, date issues, location issues, outliers). Cleanup prompts add transformation tools (ensure_clean_table, standardize_country_codes, standardize_date_column, etc.).

Occasionally a Memory Action Applied entry appears between steps -- this is the agent recording context for its own use and can be ignored.

Error Recovery

If the agent encounters a validation error on a tool call (e.g., a column stored as TEXT when a numeric type was expected, or a missing parameter), the log shows the error and the agent's automatic adjustment. The agent reasons about the failure in a Thinking block and retries with corrected parameters. Users do not need to intervene.

Agent Response

At the end of the run, the agent produces a structured summary of everything it discovered or changed. This is the most important section of the log for understanding outcomes:

For profiling prompts, this section reports what was found across all tables -- schema details, missing data percentages, date format inconsistencies, location quality issues, numeric anomalies, and recommendations for next steps. For cleanup prompts, it reports which tables were modified, what transformations were applied, how many rows were affected, and confirmation that originals are preserved.

Execution Summary

The log ends with runtime statistics and the full list of skills that were available to the agent:

Input Requirements

What the agent expects in your database:

The agent works with any tables in the selected database. There are no fixed column name requirements -- the agent discovers the schema automatically. However, for best results:

• Tables should be loaded in the database before running the agent.
• If you need unit conversion, include a uom (units of measure) reference table with columns for unit name, symbol, type, and conversion ratio.
• Postal code tools work best when postal code columns are TEXT type. The agent will cast INT/BIGINT columns to TEXT automatically if needed.

Output Description

Data Profiler or Data Cleanser Agent

To help you decide if you should use the Data Profiler or Data Cleanser Agent for your task, here is a quick overview of both:

Tips & Notes

• Start with profiling. Before asking the agent to fix anything, run a profiling prompt like "List all tables and analyze their data quality" to understand what's there. The agent will not auto-fix issues unless you explicitly ask it to.
• Be specific. "Fix postal codes" is good; "Fix postal codes in the customers and shipments tables -- repair Excel corruption, remove placeholders, and clean formatting" is better. The more specific the prompt, the more precise the results.
• Original data is safe. The agent always creates clean_* copies before making changes. Your source tables are never modified. You can re-run the agent as many times as needed.
• Order matters for postal codes. The agent handles this automatically, but for reference: Excel corruption must be repaired before formatting cleanup, and formatting must be cleaned before placeholder removal.
• Grouped fills are supported. For missing data, you can ask for strategies like "fill missing credit_limit using the median grouped by customer_segment" and the agent will handle the grouped calculation.
• Custom SQL is available. If you need something the specialized tools don't cover -- like creating views, adding computed columns, or complex joins -- the agent can execute arbitrary SQL as a fallback.
• Runtime varies based on the number of tables, columns, and the complexity of the prompt. Simple profiling tasks complete quickly; full database-wide cleanup across many tables will be longer. Expect at least a few minutes for multi-table operations.
• Just like many other DataStar tasks, it is possible to run multiple tasks in parallel with the Data Cleansing Agent.
• Additional info on the run can be found in Run Manager > Job Log after the run finishes. This includes steps that the agent takes, tools it calls, as well as a summary of work.
• The Run Utility task also offers the ability for users to set Run Configuration (optional): Tags for easy filtering in Run Manager, Timeout for maximum run duration, and Resource Size for different memory/CPU allocations.
• Duplicates are handled by a dedicated sub-agent. Any prompt that mentions finding, detecting, or merging duplicate records ("find duplicate customers", "deduplicate the suppliers table") is automatically routed to the Deduplication sub-agent. You don't need to invoke it explicitly -- the parent agent decides.
• Use the Data Profiler pipeline for deep analysis. To run a full database profile, ask for it by name (e.g., "run the data profiler pipeline"). It's a separate, longer-running workflow that persists its findings; a follow-up cleanup prompt like "fix the CRITICAL issues the Data Profiler flagged" reuses those without re-profiling. See the Data Profiler AI Agent help article for what it captures.
• ‍Append "and write a report" to get a deliverable. Adding phrases like "write a report", "save a report", or "create a report" to any analysis or cleanup prompt produces a markdown or HTML report file alongside the database changes.
• ‍Comprehensive cleanup is a full sweep. A prompt like "clean the whole database" or "audit the database" triggers an eight-category scan covering schema and freshness, missing values and sentinels, date issues, string and identifier formatting, type mismatches, cross-column logical inconsistencies, referential integrity, and statistical outliers. The agent profiles every category first, then applies fixes -- so partial-completion exits don't happen.

Examples

Example 1: Exploration (Simple)

A user wants to understand what data is in their database before deciding what to clean.

Database: Supply Chain Dataset

Task Description: List all tables in the database and show their schemas

What happens: The agent calls get_database_schema for all tables and exits with a structured report.

Output:

Requested: List all tables and show schemas.

Discovered (schema 'starburst'):

• customers: 25 rows, 11 columns (customer_id, customer_name, email, country, city, ...)
• inventory: 40 rows, 9 columns
• orders: 35 rows, 9 columns
• products: 30 rows, 11 columns
• shipments: 37 rows, 13 columns
• suppliers: 21 rows, 10 columns
• warehouses: 25 rows, 10 columns
• uom: 34 rows, 5 columns

...

Total: 12 tables, 405 rows, 112 columns

Example 2: Comprehensive Cleanup (Complex)

A user needs to clean up customer location data before using it in a Cosmic Frog network optimization model.

Database: Supply Chain Dataset

Task Description: Clean the customers table completely: standardize dates to ISO, fix postal codes (Excel corruption + placeholders), standardize country codes to alpha-2, clean city names, and normalize emails to lowercase

What the agent does:

1. Discovers the customers table schema (11 columns, 30 rows).
2. Profiles the data and finds:
   
   • 6 different date formats in registration_date
   • 11 different country representations (USA, US, United States, usa, etc.)
   • 4 Excel-corrupted postal codes in scientific notation (e.g., 9.0021E+04)
   • 5 placeholder postal codes (N/A, XXXXX, ?????, -----)
   • Inconsistent city casing and whitespace (NEW YORK, los angeles, sydney )
   • Mixed-case emails (GLOBAL@EXAMPLE.COM)

3. Creates clean_customers as a safe working copy.
4. Applies fixes in the correct order:
   
   • Standardizes all dates to ISO format (YYYY-MM-DD)
   • Repairs corrupted postal codes (9.0021E+04 becomes 90021)
   • Removes placeholder postal codes (set to NULL)
   • Standardizes countries to ISO alpha-2 (USA becomes US, Germany becomes DE)
   • Cleans city names (los angeles becomes Los Angeles, sydney becomes Sydney)
   • Normalizes emails to lowercase

5. Verifies all transformations were applied correctly.

Output:

Completed data cleansing of clean_customers table:

• Standardized 30 date values in registration_date to ISO format (YYYY-MM-DD)
• Fixed 4 Excel-corrupted postal codes (scientific notation)
• Removed 5 placeholder postal codes (set to NULL)
• Standardized 30 country codes to ISO alpha-2 format
• Cleaned 30 city names (casing, whitespace)
• Normalized 30 email addresses to lowercase

All changes applied to clean_customers (original customers table preserved).

The cleaned data is available in the clean_customers table in the database. The original customers table remains untouched.

Example 3: Enterprise Multi-Table Cleanup (End-to-End)

A user with a 14-table enterprise supply chain database needs to clean and standardize all data before building Cosmic Frog models for network optimization and simulation.

Database: Enterprise Supply Chain

Task Description: Perform a complete data cleanup across all tables: standardize all dates to ISO, standardize all country codes to alpha-2, clean all city names, fix all postal codes, and normalize all email addresses to lowercase. Work systematically through each table.

What the agent does: The agent works systematically through all tables -- standardizing dates across 12+ tables, fixing country codes, cleaning city names, repairing postal codes, normalizing emails and status fields, detecting and handling negative values, converting mixed units to metric, validating calculated fields like order totals, and reporting any remaining referential integrity issues. This is the most comprehensive operation the agent can perform.

Output: A detailed summary covering every table touched, every transformation applied, and a final quality scorecard showing the before/after improvement.

Example 4: Deduplication (Sub-agent Delegated)

A user has multiple records for the same customer in the customers table and wants golden keys created and propagated to the orders table.

Database: Supply Chain Dataset

Task Description: Find duplicate customer records in the customers table, create golden key mappings, and propagate them to the orders table.

What the agent does: Delegates the task to the Deduplication sub-agent, which detects exact and fuzzy duplicate groups, picks a canonical record for each group, and updates the orders table so every order points to the canonical customer.

Output: A summary listing how many duplicate groups were detected, how many golden keys were created, and how many rows in orders were updated to point to the canonical master record.

Example Prompts

Below are example prompts users can try, organized by category.

Exploration & Profiling

1. "List all tables in the database and show their schemas"
2. "Check for date format issues across all tables that have date columns"
3. "Detect all postal code data quality issues in customers, shipments, suppliers, and warehouses tables"
4. "Detect outliers in product prices, inventory quantities, and order amounts. Use IQR method."

Simple Fixes

1. "Standardize all dates in the orders table to ISO format"
2. "Standardize all country codes in the customers table to ISO alpha-2 format (US, DE, etc)"
3. "Fill missing processor_fee values in transactions with 0.0"
4. "Standardize all email addresses to lowercase across employees, customers, suppliers. Also trim whitespace."

Complex Multi-Step Tasks

1. "Clean all postal codes in the customers table: fix Excel corruption, remove placeholders, clean formatting. Follow the proper postal code cleaning workflow."
2. "Standardize ALL date columns across orders, transactions, inventory, products, and customers to ISO format"
3. "Convert all product weights to kilograms and all lengths to centimeters. Some products already have metric, some have imperial, some have both - handle this correctly."
4. "Fill missing credit_limit values in customers using the median credit_limit grouped by customer_segment"
5. "Find cross-column inconsistencies in orders: delivery dates before ship dates, totals that don't equal price * quantity, and rows marked status=shipped but missing ship_date -- report only, don't fix"

End-to-End Scenarios

1. "Clean the customers table completely: standardize dates to ISO, fix postal codes (Excel corruption + placeholders), standardize country codes to alpha-2, clean city names, and normalize emails to lowercase"
2. "Perform a complete data cleanup across all tables: standardize all dates to ISO, standardize all country codes to alpha-2, clean all city names, fix all postal codes, and normalize all email addresses to lowercase. Work systematically through each table."
3. "Prepare the entire database for data warehouse ETL: clean all tables, ensure referential integrity, standardize all formats, validate all calculations. Generate final quality report."

Custom SQL

1. "Create a view called customer_summary that shows customer_id, total number of orders, and total order amount from the orders table"
2. "Update the shipments table to add a new column called 'is_international' (boolean) that is TRUE when ship_from_country differs from ship_to_country"

Deduplication & Referential Integrity

1. "Find duplicate customer records in the customers table and report them, but don’t change anything"
2. "Deduplicate the suppliers table end-to-end: detect duplicates, create golden keys, and propagate them to all referencing transaction tables"
3. "Validate referential integrity across the database -- show orphan records and recommend fixes, but wait for me to approve before changing anything"

Data Profiler Pipeline

1. "Run the data profiler pipeline on the full database"
2. "Run the data profiler on only the customers and orders tables"
3. "Based on the latest data profiler run, fix the CRITICAL alerts in the clean_* tables"

Reports

1. "Profile every table for data quality issues and write a markdown report summarizing what you found"

2. "Clean the customers table and produce an HTML report of every transformation you applied"

Other Helpful Resources

• Learn more about Cosmic Frog
• Learn more about DataStar
• Getting Started with Ada & Agentic AI
• An overview of Optilogic's AI Agents and Utilities
• AI Agents: Architecture and Components
• The Modeler AI Agent
• The Model Output Insights AI Agent
• The Data Profiler AI Agent

Questions or feedback? Please contact the Optilogic Support team on support@optilogic.com.

Overview

The Data Profiler AI Agent is one of Ada's AI-powered assistants, focused on assessing data. It automatically analyzes the quality, structure, and relationships of data stored in an Optilogic database. By profiling every table and column, the agent creates a comprehensive data-quality catalog that helps users understand their data, identify issues, discover relationships, and prioritize cleansing efforts.

The agent can be accessed by chatting with Ada in the next generation Optilogic platform and via Run AI Agent tasks in DataStar.

Why Use the Data Profiler AI Agent?

Understanding the quality and meaning of data is often one of the most time-consuming steps in any analytics, modeling, or optimization project. The Data Profiler AI Agent automates this process by:

• Generating detailed statistical profiles for tables and columns
• Creating business-friendly descriptions of tables and fields
• Detecting data-quality issues and anomalies
• Identifying potential primary and foreign key relationships
• Recommending appropriate data types
• Assigning quality scores to help prioritize remediation efforts
• Maintaining historical profiling results for trend analysis

The result is a queryable inventory of your data assets, complete with quality assessments and relationship insights.

What the Agent Does

The Data Profiler AI Agent performs several layers of analysis.

Statistical Profiling

For every table and column, the agent calculates statistical characteristics such as:

• Row counts
• Column counts
• Missing value percentages
• Distinct value counts
• Percentiles
• Skewness
• Zero-value frequency
• Interquartile range (IQR) outlier detection
• Pearson correlations between column pairs

For large datasets, the agent uses deterministic sampling to ensure consistent results across profiling runs.

Table and Column Documentation

Using LLM-assisted analysis, the agent generates:

• Executive summaries for tables
• Descriptions for each column
• Classification of tables as either:
  • Master Data
  • Transactional Data
• Semantic classifications for columns, such as:
  • Email
  • Postal code
  • Currency
  • Identifier
  • Date
  • Phone number
  • Geographic coordinate

These descriptions help users quickly understand the purpose and meaning of data assets.

Cast-Type Recommendations

Based on semantic classifications, the agent recommends appropriate database data types. Examples include:

• currency → NUMERIC
• identifier → TEXT to preserve leading zeros
• date → DATE or TIMESTAMP

These recommendations help improve data consistency and prevent issues such as loss of leading zeros in identifiers.

Semantic Data Validation

After semantic types are identified, the agent performs specialized validation checks against actual data values. Examples include:

• Malformed email addresses
• Deprecated currency codes
• Mixed phone number formats
• Ambiguous date formats
• Out-of-range geographic coordinates
• Placeholder/sentinel values
• Hidden control characters
• Excessive whitespace
• Padded categories

The agent performs dozens of validation checks tailored to the detected semantic type.

Alert Generation

Each detected issue is stored as a single row structured alert. Each alert contains:

• Check name
• Category
• Severity (CRITICAL / MEDIUM / LOW)
• Affected table and column
• Human-readable explanation

Notable specialized checks include:

• Null-sentinel strings in text columns - values such as "N/A", "-", "None", etc. that masquerade as data
• Fixed-width truncation patterns - column values silently cust at 16, 32, 255 characters
• Shadow columns - near-perfect correlation suggesting a duplicate/linear transform
• Row-count drift - significant row-count changes between profiling runs

Primary and Foreign Key Discovery

The agent can identify relationships even when keys are not formally defined in the schema.

The discovery process includes

• ‍Heuristics on column names and uniqueness stats propose candidates.
• SQL probes validate uniqueness, null rates, and FK match rates against actual rows.
• LLM interpretation resolves ambiguous candidates; an optional pass suggests relationships heuristics missed.‍
• Composite primary keys (2–4 columns) are tested and the minimal unique set is returned.

Data Quality Scoring

The Data Profiler AI Agent assigns scores ranging from 0.0 to 1.0 across three dimensions:

• Data reliability — values present, valid, in range. ‍
• Integrity and completeness — structural soundness, duplicates, Primary Key/Foreign Key health. ‍
• Cross-consistency — uniformity of format and encoding.

The overall score is a weighted average, which is capped if data integrity drops too low. Tables without data receive a baseline minimum score, while tables that generate errors display an error stub so users are always aware of the issue.

Data Reliability

Measures whether values are:

• Present
• Valid
• Within expected ranges

Cross-Table Consistency Analysis

When the same column name appears in multiple tables with different semantic tags, a majority vote picks one and corrects the outliers.

Inputs and Outputs

Inputs

The only required input is to point the agent to a database. There are several optional inputs which we will cover in the Using the Data Profiler Agent section below.

Outputs

The output consists of tables written to the database that was profiled:

In addition to database outputs, the agent generates a timestamped execution log, which includes table processing times, alerts, and primary key/foreign key findings. Reviewing the log can help diagnose profiling issues and understand execution performance.

Using the Data Profiler Agent

There are two ways to access the Data Profiler Agent:

1. By using Run AI Agent tasks within DataStar
2. Through chatting with Ada in the next generation Optilogic platform

Both ways will be explained, through DataStar first, then using the chat UI.

Using the Data Profiler Agent within DataStar

Accessing the Data Profiler Agent through DataStar is done via a Run AI Agent task:

In the Configure Utility section of the Configuration tab (from top to bottom):

1. Database (required) - choose the database, a Cosmic Frog model, DataStar project or Postgres database, to be profiled.
2. Table Selection (optional) - by default All Tables in the database will be profiled. Switch to Specific Tables if profiling a subset, which will require listing the tables to be profiled inthe Tables to Profile field that will come up.
3. Max Rows to Sample (optional) - by default a maximum of 100,000 rows per table will be profiled. Set to a different number if required. Setting to 0 means profile all rows, which may be time-consuming for large tables.
4. Profile Mode (optional) - by default the full pipeline performing all the profiling steps as described in the What the Agent Does section above will be run. For a faster result switch to "Statistics + Alerts + Scoring" which omits the descriptions, semantic checks, and primary key/foreign discovery.
5. Max Table Workers (optional) - by default up to 16 tables can be processed concurrently. Lower this for very large databases.
6. Cache Descriptions (optional) - by default descriptions and semantic type are generated fresh ("Refresh") when running the data profiler. Switch to "Reuse" to use the descriptions and semantic types from the previous Data Profiler run if the table's columns are unchanged.

Note that it is recommended to change the Resource Size from 3XS to XS in the Run Configuration section, since 3XS is usually not sufficient to run the Data Profiler Agent:

While the task is running and after it has completed, the Task Logs tab contains the log file where the user can monitor progress and review key alerts and high-level output summaries:

As an example output, let us have a look at the _dq_table_profiles table:

In this table, the entire executive summary for the customer_returns table is as follows: "The customer_returns table records return events tied to individual sales order lines, supporting analysis of return volumes, reasons, and financial impact. Each record links a return reference return_id to an order_line_id, with return_date providing the time dimension for trend reporting. Operational metrics include return_qty and restock_flag, while refund_amount captures the customer reimbursement value but is stored as text and includes invalid entries. Return reasons are mostly standardized but include missing values and placeholder or corrupted categories, suggesting a need for data cleansing and validation."

Using the Data Profiler Agent within the Chat UI

It is recommended to be somewhat familiar with Ada and how to talk to her in the chat UI before diving into this content. Please see the Getting Started with Ada & Agentic AI article, and in particular its How to Use Ada section.

Once logged into the next generation Optilogic platform at https://ai.optilogic.app, you can start chatting with Ada and leveraging the Data Profiler Agent right away from the central part of the Home page. You can access it by using the Data Cleanser Agent, as this agent can call the Data Profiler Agent as a tool.

‍

After selecting the database to profile (here a DataStar project named Dairy End-to-End Ada), set the agent to Data Cleanser, write your prompt indicating you want to profile the data (or a subset of it) contained in the connected database. It is recommended to mention the Data Profiler pipeline and wanting to write the results into the database itself:

This prompt results in running the full Data Profiler Agent's pipeline and the __pq_ tables can be found in the sandbox of the connected DataStar project.

Use DataStar or Chat UI?

The following table summarizes the most common use cases for the 2 ways of accessing the Data Profiler Agent:

Data Profiler or Data Cleanser Agent

To help you decide if you should use the Data Profiler or Data Cleanser Agent for your task, here is a quick overview of both:

Summary

You point the Data Profiler AI Agent at a database, walk away, and come back a few minutes later to a queryable catalogue of every table — what each column means, what type it should be, where the data is broken, how the tables relate, and a single quality score per table to triage what needs cleaning first.

Other Helpful Resources

• Getting Started with Ada & Agentic AI‍
• An overview of Optilogic's AI Agents and Utilities‍
• AI Agents: Architecture and Components‍
• The Modeler AI Agent
• The Model Output Insights AI Agent‍
• The Data Cleansing AI Agent
• Learn more about Cosmic Frog‍
• Learn more about DataStar

Questions or feedback? Please contact the Optilogic Support team on support@optilogic.com.

‍

Overview

The Full Truckload Costing utility solves the common problem of missing transportation cost data when building supply chain models. Rather than requiring users to manually research rates for every lane, this workflow automatically derives costs from a company's existing shipment history. The utility expects two input tables: a lanes-to-cost table containing the origin-destination pairs that need pricing, and an optional historical shipments table containing preprocessed cost data. After running the utility, users receive a fully costed lanes table with confidence levels for each estimate.

The Full Truckload Costing Utility is available on the Resource Library, from which you can download it or copy it to your Optilogic account. Learn more about the Resource Library in this How to use the Resource Library help center article.

What's Included

Sample Data

• Sample lanes_to_cost CSV file (5,000 lanes across North America)
• Sample historical_shipments_processed CSV file (3,500 historical lane costs)

System Utility

• Full Truckload Costing utility accessible via the "Run Utility" task in DataStar

How To Use

The steps to use this utility are as follows. These are illustrated with screenshots below.

1. Prepare your input data:
   • Create a lanes_to_cost table with all required columns (see Input Requirements)
   • Optionally create a historical_shipments_processed table with your preprocessed historical data
   • Ensure data passes validation requirements (unique keys, no NULLs in join columns, valid postal codes)
2. Upload your data to a database in DataStar
3. Run the utility:
   • Open the "Run Utility" task in DataStar
   • Select "Full Truckload Costing" from the available utilities
   • Configure the parameters:
     • Database: Select your Optilogic database
     • Schema: Select the schema containing your tables
     • Lanes Table: Select your lanes_to_cost table
     • Historical Table: (Optional) Select your historical_shipments_processed table
     • Output Table: Specify the output table name (defaults to lanes table name + "_output")
     • Keep Working Tables: Toggle on to retain intermediate tables for debugging
     • Verbose: Toggle on for detailed logging
4. Review the output table containing costed lanes with confidence levels

Screenshots of the steps:

Input Requirements

Lanes to Cost Table (Required)

Key Constraints:

• Each combination of (origin_id, destination_id, mode, product, cost_type) must be unique
• No NULL values allowed in: origin_id, destination_id, mode, product, cost_type, origin_postal_code, destination_postal_code

Historical Shipments Processed Table (Optional)

Key Constraints:

• Each combination of (origin_id, destination_id, mode, product, cost_type) must be unique
• Historical data must be preprocessed: outliers removed, costs aggregated to one value per unique lane
• No NULL values allowed in join columns

Output Description

The utility produces an output table containing all lanes from the input with the following additional columns populated:

Costing Pipeline

The utility processes lanes through a sequential pipeline, with each step only processing lanes that still have NULL costs:

1. Validation - Verifies input data meets all requirements
2. Copy & Enrich - Creates working copies and adds distance bands and DAT regions
3. Exact Match - Matches on (origin_id, destination_id, mode, product, cost_type) - Confidence: Very High
4. Approximate Match - Progressive geographic relaxation:
   • Full Postal Code Match - Confidence: High
   • ZIP-3 Match - Confidence: Med
   • State Match - Confidence: Med-Low
   • DAT Region Match - Confidence: Low
5. Fallback Costing - For lanes without historical matches:
   • Segmented average by cost_type/distance_band/mode - Confidence: Med
   • DAT Region benchmark rates - Confidence: Med-Low
   • Overall average $/mile - Confidence: Low
   • Default rate ($1.60/mile) - Confidence: Very Low
6. Copy to Output - Writes final results to output table

Tips & Notes

• If no historical shipments table is provided, the utility will skip exact and approximate matching and only apply fallback costing using default benchmark rates.
• The workflow is fully deterministic - given the same inputs, it will always produce the same outputs.
• Original input tables are never modified. The utility creates working copies for all processing.
• For best results, ensure your historical shipments table has good coverage of the geographic regions and product types in your lanes to cost.
• Lanes with "Very Low" confidence (default rate) indicate gaps in your historical data. Consider collecting actual rate quotes for these lanes.
• The DAT Region mapping covers the continental US, Canada, and Mexico. US states are mapped to 10 freight regions (Z0-Z9) based on typical freight market patterns.
• Distance bands help match lanes with similar characteristics: <25 miles (short haul), 25-250 miles (regional), >250 miles (long haul).

Other Helpful Resources

• Learn more about Cosmic Frog
• Learn more about DataStar
• An overview of Optilogic's AI Agents and Utilities
• The Less-Than-Truckload Costing Utility, also available from within DataStar
• The Air Express Freight Costing Utility, also available from within DataStar

‍

Overview

The Less Than Truckload Costing utility solves the challenge of pricing less-than-truckload (LTL) shipments when carrier rate data is complex and varies by service level, distance, and weight. Rather than manually looking up rates in carrier tariff tables, this workflow automates the entire process using FedEx Express Freight standard list rates. The utility expects a lanes-to-cost table containing shipment details including origin, destination, distance, weight, and desired service level. After running the utility, users receive a fully costed table with calculated transportation costs.

The Less Than Truckload Costing Utility is available on the Resource Library, from which you can download it or copy it to your Optilogic account. Learn more about the Resource Library in this How to use the Resource Library help center article.

What's Included

Sample Data

• Sample lanes_to_cost CSV file (5,000 lanes across the US)

System Utility

• Less Than Truckload Costing utility accessible via the "Run AI Agent" task in DataStar
• Built-in FedEx Express Freight rate tables (automatically loaded by the utility)

How To Use

The steps to use this utility are as follows. These are illustrated with screenshots below.

1. Prepare your input data:
   • Create a lanes_to_cost table with all required columns (see Input Requirements)
   • Ensure distances are calculated in miles
   • Assign appropriate service levels to each shipment
   • Set the destination_rural flag correctly for Alaska/Hawaii destinations, see also the Tups & Notes section
2. Upload your data to a database in DataStar
   • Upload the file to your Optilogic account
   • Create a data connection to it in DataStar
   • Import the data into the project sandbox by using an Import task
3. Run the utility:
   • Open the "Run AI Agent" task in DataStar
   • Select "Less Than Truckload Costing" from the available utilities
   • Configure the parameters:
     • Database: Enter your database name
     • Schema: Select the schema containing your table
     • Lanes Table: Select your lanes_to_cost table
     • Output Table: Specify the output table name
     • Keep Working Tables: Toggle on to retain intermediate tables for debugging
     • Verbose: Toggle on for detailed logging
4. Review the output table containing costed lanes

Screenshots of the steps:

Input Requirements

Lanes to Cost Table (Required)

Key Constraints:

• No NULL values allowed in any required column
• Service level values must be lowercase and match exactly: "economy" or "priority"
• Freight class must be a valid NMFC class value (see Supported Freight Classes below)
• Weights must be positive numbers in pounds
• Postal codes must be exactly 5 digits
• Zones must be integers between 101 and 150 (inclusive)

Output Description

The utility produces an output table containing all lanes from the input with the following additional columns populated:

Cost Calculation

LTL costs are calculated as a three-component sum:

• cost = line_haul charge + origin_ accessorial_ charge + destination_accessorial_ charge

Each component is calculated independently using the formula:

• component_charge = MAX(rate_ per_ 100lbs x (weight_ lbs / 100), minimum_ charge)

Where:

• Line-Haul Charge: Determined by service level, freight class, zone, and weight band from the FedEx zone-based rate table
• Origin Accessorial Charge: Determined by service level, freight class, the origin pickup tier (derived automatically from the origin postal code), and weight band.
• Destination Accessorial Charge: Determined by service level, freight class, the destination delivery tier (derived automatically from the destination postal code), and weight band.
• Pickup/Delivery Tiers: The utility automatically looks up origin and destination tiers (A through I) using the postal codes provided. You do not need to supply tiers in your input data.

Zone Reference

FedEx Freight zones (101–150) represent the transit distance and pricing tier between an origin and destination. Zones are assigned by FedEx based on origin and destination ZIP codes. You can determine the correct zone for a lane using the FedEx Freight zone chart or a zone lookup tool.

Higher zone numbers generally correspond to longer distances and higher rates.

Supported Freight Classes

The utility supports the following standard NMFC freight classes:

Freight class values are case-insensitive and will be normalized automatically. Common formats such as "60", "60.0", and "60.00" are all accepted and treated as equivalent.

Service Levels

Service level values are normalized to lowercase automatically, so "Economy", "ECONOMY", and "economy" are all accepted.

Failure Reasons

If a lane cannot be costed, the failure_reasons column will contain one or more of the following:

‍

Tips & Notes

• The workflow is fully deterministic - given the same inputs, it will always produce the same outputs.
• Original input tables are never modified. The utility creates working copies for all processing.
• The FedEx rate tables are built into the utility and are automatically loaded. You do not need to provide rate data.
• Freight zones (101–150) must be determined prior to running the utility. These can be looked up using a FedEx Freight zone chart based on origin and destination ZIP codes.
• Origin and destination pickup/delivery tiers are derived automatically from postal codes. You do not need to supply tier information in your input data.
• Lanes with a non-empty failure_reasons column were not costed. Review the failure reasons to identify and fix data quality issues before re-running.
• Freight class values are normalized automatically. You do not need to ensure a specific format (e.g., "60" and "60.0" are treated identically).
• Service level values are normalized to lowercase automatically, so mixed-case input is accepted.
• This utility currently supports US domestic less-than-truckload shipments only.

Other Helpful Resources

• Learn more about Cosmic Frog
• Learn more about DataStar
• An overview of Optilogic's AI Agents and Utilities
• The Full Truckload Costing Utility, also available from within DataStar
• The Air Express Freight Costing Utility, also available from within DataStar

‍DataStar is Optilogic’s new AI-powered data product designed to help supply chain teams build and update models & scenarios and power apps faster & easier than ever before. It enables users to create flexible, accessible, and repeatable workflows with zero learning curve—combining drag-and-drop simplicity, natural language AI, and deep supply chain context.

Today, up to an estimated 80% of a modeler's time is spent on data—connecting, cleaning, transforming, validating, and integrating it to build or refresh models. DataStar drastically shrinks that time, enabling teams to:

• Answer more questions faster‍
• Unlock repeatable value across business review‍
• Focus on strategic decisions, not data wrangling

The 2 main goals of DataStar are 1) ease of use, and 2) effortless collaboration, these are achieved by:

• Providing AI-powered, no-code automation with deep supply chain context‍
• Supporting drag-and-drop workflows, natural language commands, and advanced scripting (SQL/Python)‍
• Full integration into the Optilogic platform: users can prep data, trigger model & scenario runs, and push insights to apps or dashboards
• Enabling scalable, collaborative, cloud-native modeling for repeatable decision-making at speed

In this documentation, we will start with a high-level overview of the DataStar building blocks. Next, creating projects and data connections will be covered before diving into the details of adding tasks and chaining them together into macros, which can then be run to accomplish the data goals of your project.

Please see this "Getting Started with DataStar: Application Overview" video for a quick 5-minute overview of DataStar.

DataStar Overview

Before diving into more details in later sections, this section will describe the main building blocks of DataStar, which include Data Connections, Projects, Macros, and Tasks.

Data Connections

Since DataStar is all about working with data, Data Connections are an important part of DataStar. These enable users to quickly connect to and pull in data from a range of data sources. Data Connections in DataStar:

• Are global to the DataStar application – meaning each project within DataStar can use any of the data sources that have been set up as Data Connections.
• Can also be set up from within a DataStar project – they then become available for use in other DataStar projects too.
• Can be of the following types currently:
  
  • Postgres – an open-source relational database management system that supports both SQL and JSON querying
  • CSV Files – files containing data in the comma separated values format, which can be created by and opened in Excel
  • Cosmic Frog Models – a Cosmic Frog model which is a Postgres database using a specific data schema called Anura. Often the projects in DataStar will populate Cosmic Frog model input tables to build complete models that are ready to be run by one of the Cosmic Frog engines and/or read in Cosmic Frog output tables for output analysis
  • Excel – spreadsheet editor developed by Microsoft for Windows (beta version)

Connections to other common data resources such as MySQL, OneDrive, SAP, and Snowflake will become available as built-in connection types over time. Currently, these data sources can be connected to by using scripts that pull them in from the Optilogic side or using ETL tools or automation platforms that push data onto the Optilogic platform. Please see the "DataStar: Data Integration" article for more details on working with both local and external data sources.

Users can check the Resource Library for the currently available template scripts and utilities. These can be copied to your account or downloaded and after a few updates around credentials, etc. you will be able to start pulling data in from external sources:

1. Go to the Resource Library application while logged in on the Optilogic platform.
2. Click on the DataStar button at the right top to filter the list of resources for those specific to DataStar.
3. Optionally, use the Tags drop-down to filter the list further down to find what you are looking for quickly. Here we have selected 2 tags: "Extensibility Tool" and "Utility".
4. Browse the list and click on a resource of interest to select it, here we clicked on the "Google Big Query Insert Script" resource.
5. After clicking on it, a description of the resource appears on the right hand-side.
6. Associated files can be downloaded by using these Download buttons.
7. The blue buttons at the right bottom can be used to gain access to this resource. Click on the Copy to Account button to start using the resource on the Optilogic platform. Scripts can for example be viewed, edited, and run in the Lightning Editor application.

‍

Projects, Macros, and Tasks

Projects are the main container of work within DataStar. Typically, a Project will aim to achieve a certain goal by performing all or a subset of importing specific data, then cleansing, transforming & blending it, and finally publishing the results to another file/database. The scope of DataStar Projects can vary greatly, think for example of following 2 examples:

• Cleanse and filter a specific set of historical supply chain data.
• Build a Cosmic Frog model from scratch using the raw data from your data sources, then run the model, analyze its outputs, and finally generate reports at the desired level of aggregation.

Projects consist of one or multiple macros which in turn consist of 1 or multiple tasks. Tasks are the individual actions or steps which can be chained together within a macro to accomplish a specific goal.

The next screenshot shows an example Macro called "Transportation Policies" which consists of 8 individual tasks that are chained together to create transportation policies for a Cosmic Frog model from imported Shipments and Costs data:

Project Sandbox

Every project by default contains a Data Connection named Project Sandbox. This data connection is not global to all DataStar projects; it is specific to the project it is part of. The Project Sandbox is a Postgres database where users generally import the raw data from the other data connections into, perform transformations in, save intermediate states of data in, and then publish the results out to a Cosmic Frog model (which is a data connection different than the Project Sandbox connection). It is also possible that some of the data in the Project Sandbox is the final result/deliverable of the DataStar Project or that the results are published into a different type of file or system that is set up as a data connection rather than into a Cosmic Frog model.

How Data Connections, Projects, and Macros Relate to Each Other

The next diagram shows how Data Connections, Projects, and Macros relate to each other in DataStar:

1. In this example, there are 7 Data Connections configured in DataStar, see the rectangle with green background on the left:
   
   • An Excel connection called Historical Data
   • A Postgres database connection called Enterprise Data
   • An Excel connection called Location Data
   • A CSV connection called Cost Data
   • A CSV connection called Capacity Data
   • A Cosmic Frog connection called Neo NA Model
   • A Cosmic Frog connection called Global Model
2. Note that the 2 Cosmic Frog connections displayed here on the right-hand side are the same 2 as shown in the list on the left, they are just repeated in the diagram to facilitate explaining the flow of data.
3. There are 2 projects set up in DataStar, see the 2 rectangles with blue background in the middle:
   
   • Project 1 creates Policies tables for the Cosmic Frog model named Neo NA Model, a network optimization model in the Northern Americas geography.
   • Project 2 builds, runs, and analyzes a complete Cosmic Frog model named Global Model from raw data.
4. Looking at Project 1, we see that:
   
   • It uses 3 of the 7 Data Connections available (blue arrows):
     
     • Two to pull data in from: the Historical Data, and Cost Data connections.
     • One to publish data into: the Neo NA Model.
   • It has its own Project Sandbox as an additional Data Connection which is specific to this project only.
   • It contains 3 macros: Shipments, Production, and Inventory. The Shipments macro can look similar to the example one seen in the previous screenshot.
   • The 3 macros pull data from the Historical Data, Cost Data, and Project Sandbox connections.
   • The 3 macros publish data into the Project Sandbox and the Neo NA model connections. The completed Transportation Policies, Production Policies, and Inventory Policies tables are published into the Cosmic Frog model.
5. Similarly, looking at Project 2, we follow the yellow arrows to understand which Data Connections are used to pull data from and publish data into. Note that the Global Model connection is used to publish results into by the “Publish to Model” macro which populates the model’s input tables and it is also used as a connection to pull data from for the “Output Analysis” macro after the model has run to completion.

As referenced above too, to learn more about working with both local and external data, please see this "DataStar: Data Integration" article.

Creating Projects & Data Connections

On the start page of DataStar, the user will be shown their existing projects and data connections. They can be opened, or deleted here, and users also have the ability to create new projects and data connections from this start page.

How to Create a New Project

The next screenshot shows the existing projects in card format:

1. When logged into the Optilogic platform, click on the DataStar icon in the list of available applications on the left-hand side to open DataStar. Your DataStar icon may be in a different location in the list, and if it is not visible at all, then click on the icon with 3 horizontal dots to show any applications that are not shown currently.
2. We are on the Projects tab of the start page in the DataStar application.
3. The projects are shown in card format (the left icon); the other option is to show them as a list (the right icon).
4. When hovering over a project, the options to edit the project (rename it and/or update its description) and to delete the project become visible. When clicking on the delete project icon, a message asking the user to confirm they want to delete the project comes up before actually deleting it.
5. Users can quickly search the list of projects by typing in the Search text box and projects containing the text will be filtered out.

New projects can be created by clicking on the Create Project button in the toolbar at the top of the DataStar application:

1. The user clicked on the Create Project button which opened the Create Project form.
2. Here, a Project Name can be entered.
3. Optionally, a Project Description can be added.
4. Under Project Type, users can either create a new Empty Project or choose to create a Project from Template. Here, we select the Empty Project option; Template Proejects are discussed in the next section.
5. Click on the Edit button to change the project’s appearance by choosing an icon and color.
6. Click on the Add Project button to create the project.
7. Note that on the right-hand side, Help for the currently open DataStar form is shown.
8. If at any point during the creation of a new project the user decides they do not want to go ahead with it, they can close the form by either clicking on the back icon at the left top or the cross icon at the right top.

Using Template Projects

If on the Create Project form a user decides they want to use a Template Project rather than a new Empty Project, it works as follows:

1. The Project from Template option has been chosen on the Create Project form.
2. This brings up a list of available template projects users can choose from. Hovering over a template project will bring up a textbox with a short description of the template project.
3. Click on a template project to select it, it will then be greyed out and unavailable to select again. In addition:
   
   1. The template project will be pinned to the top of the list with a darker background to indicate that this is the currently selected template project.
   2. The project name will be automatically filled out with the name of the selected template project.
   3. Users can choose to add an optional description.
4. When a template project is selected, information about it will be shown on the right-hand side of the Create Project form.
5. A preview of detailed documentation of the template project is shown too. Options for zooming, downloading and printing are available for this documentation; click on the icon with 3 vertical dots to see all options.
6. Like with new empty projects, the icon and background color for the template project can be edited by clicking on the Edit button.
7. Click on Add Project to make the project available from within DataStar. It will now appear on the Projects tab on DataStar's start page.

These template projects are also available on Optilogic's Resource Library:

1. Go to the Resource Library application while logged in on the Optilogic platform.
2. Click on the DataStar button at the right top to filter the list of resources for those specific to DataStar.
3. Use the Tags drop-down to filter the list further down to those that are tagged with "Project".
4. Browse the list and click on a project of interest, here we clicked on the "Detect and Report Outliers" resource.
5. After clicking on it, a description of the resource appears on the right hand-side.
6. Associated files can be downloaded, a script and documentation in PDF format are available for download for this resource.
7. The blue buttons at the right bottom can be used to gain access to this resource. Click on the Copy to Account button to start using this project in DataStar.

After the copy process completes, we can see the project appear in the Explorer and in the Project list in DataStar:

1. We have expanded the Explorer application to see the files and folders in our Optilogic account.
2. Under /My Files/DataStar, a new folder "Profile and Cleanse Data" was created. It contains 1 file with a .dstar extension, this is a DataStar project database (underneath a Postrges database).
3. In the central part of the platform DataStar is the active application as that is the one selected in the list of applications.
4. We are on the Projects tab on the start page in DataStar.
5. The list of projects is shown in list format here where the most recent project is shown at the top of the list. This is the "Profile and Cleanse Data" project we just copied from the Resource Library. Click on it to open it and start exploring.

Note that any files needed for data connections in template projects copied from the Resource Library can be found under the "Sent to Me" folder in the Explorer. They will be in a subfolder named @datastartemplateprojects#optilogic (the sender of the files).

How to Create a New Data Connection

The next screenshot shows the Data Connections that have already been set up in DataStar in list view:

1. We are on the Data Connections tab of the start page in the DataStar application.
2. The Data Connections are shown in list format (right icon); the other option is to show them in card format (left icon) similar to the screenshot above of the Projects in card format.
3. For each Data Connection we see the following details in the list: Name, Connection Type, Description, Created At, Owner, Last Edited, and Actions. Clicking on the column headers sorts the table by that column in ascending order, clicking again will sort in descending order, and clicking a third time takes the sort off. Holding both the Shift and Ctrl buttons down and next clicking on multiple column headers will sort the table by those multiple columns.
   
   1. Note that when hovering over the Actions field in a data connection row, icons to rename and delete the connection become visible. When users click on the delete icon, a message asking the user to confirm they want to delete the data connection comes up before actually deleting it.
4. Users can quickly search the list of data connections by typing in the Search text box and connections containing the text will be filtered out.

New data connections can be created by clicking on the Create Data Connection button in the toolbar at the top of the DataStar application:

1. The Create Data Connection form has been opened by clicking on the Create Data Connection button.
2. First, a Data Connection Name needs to be entered.
3. Optionally, the user can write a Connection Description.
4. The type of connection can be chosen from the Connection Type drop-down list. See the “Data Connections” section further above for a full list of connection types and a short description of each.

The remainder of the Create Data Connection form will change depending on the type of connection that was chosen as different types of connections require different inputs (e.g. host, port, server, schema, etc.). In our example, the user chooses CSV Files as the connection type:

1. The Connection Type is now showing CSV Files per the selection user made.
2. There are 2 options to select the CSV source file:
   
   1. The CSV file to be used for the Data Connection can be dragged and dropped onto this “Drag and drop” area from user’s computer. It will then be uploaded to the user’s /MyFiles/DataStar folder on the Optilogic platform. In case a file of the same name already exists in that location, it will be overwritten.
   2. The user can browse the list of CSV files that exist in their Optilogic account already (not limited to files under /MyFiles/DataStar, will show all CSV files in their account) to select one as the source for the data connection. Note that:
      
      1. We can quickly find files of interest by typing in the Search box at the top of the list to filter out any files containing the typed text in their names.
      2. In case not all 3 columns shown in the screenshot are visible, users can scroll right to also see the location in user’s Optilogic workspace of the file.
      3. Options to customize the grid to users' needs (e.g. sorting, changing the order of columns, etc.) are explained in the Appendix.
3. After selecting the CSV file to be used for the Data Connection, users can optionally configure the data connection further with the options provided on the right-hand side of the form. See the CSV File Data Connection help center article for more details on these configuration options. Once done configuring the data connection, click on the Add Connection button to create the new data connection.

In our walk-through here, the user drags and drops a Shipments.csv file from their local computer on top of the Drag and drop area:

1. The user dragged and dropped their local Shipments.csv file onto the “Drag and drop” area.
2. Once the upload of the file is finished, a message in green font indicating the upload completed successfully is shown.
3. The Shipments.csv file is now listed in the list of CSV files the user has available in their Optilogic account. As expected, the location of this file is /MyFiles/DataStar. When clicking on the file in the list to select it, it becomes greyed out to indicate it is already selected.
4. The selected file will be pinned to the top of the list, to prevent the user having to scroll through the list to find the currently selected file.
5. The user can optionally configure any of the options provided on the right-hand side of the form, and then click on the Add Data Connection button to create the connection.

Inside a DataStar Project

Now let us look at a project when it is open in DataStar. We will first get a lay of the land with a high-level overview screenshot and then go into more detail for the different parts of the DataStar user interface:

1. At the top of the DataStar application, users will find a toolbar, which contains following options from left to right:
   
   • Clicking on the back button all the way to the left will take user back to DataStar’s start page where the lists of existing projects and data connections are shown, see also the previous section “Creating Projects & Data Connections”.
   • Create Macro button: click on this button to create a new Macro.
   • Create Data Connection button: click on this button to create a new Data Connection.
   • Table Functions drop-down menu. When a table from a data connection is open in DataStar, this menu will become available and allows a user to export the table to CSV or open it in the SQL Editor application on the Optilogic platform. See also the "Viewing a Connection's Table" section further below.
   • Manage Variables button: in future, this button will be enabled so users can pass in values that can be used/updated in their macros.
   • Ask Leapfrog AI button: this opens the Leapfrog window. Start or continue a conversation with Leapfrog here. Use natural language prompts and Leapfrog will configure Update and Run SQL tasks for you! See the Leapfrog section further below for more details.
   • The Run button is used to start any task or macro runs.
2. In the pane on the left-hand side of the application, either the list of Macros that the project contains (left tab) or the list of available Data Connections (right tab) is shown. In this screenshot, the Macros tab is the active tab.
   
   • Macros can be expanded/collapsed; when expanded you see a list of all the tasks/macros that make up the macro. This will be shown in more detail below.
   • Likewise, data connections can also be expanded/collapsed; when expanded you see the available schemas for database connections and (for all connection types) the tables contained in the data connection.
3. In the pane on the right-hand side of the application, there are 2 tabs:‍
   
   • Tasks – from here tasks can be chosen and dragged and dropped onto the Macro Canvas (the central part of the DataStar application) to add them to the currently active macro.‍
   • Configuration – the specific configuration parameters for the currently selected task can be set or updated here.
4. The central part of DataStar is called the Macro Canvas. Tasks can be dragged and dropped onto here and then connected to each other to build out a macro that will accomplish a specific data process. The macro canvas becomes active when the user clicks on a macro or one of its tasks in the Macros tab on the left. The macro name is also listed in the tab at the top of the canvas.‍
5. Tables present in any of the Data Connections can also be shown in the central part of DataStar by clicking on them in the Data Connections tab. This shows as an additional tab across the top of the macro canvas. Multiple macros and tables can be opened here at the same time, and users can switch between them by clicking on the tab of the macro/table they wish to show.
6. Logs – the Macro Logs and Task Logs tabs are located at the bottom of the Macro Canvas. Here macro and individual task runs are tracked: which task was run when and did it complete successfully. When using Run AI Agent and Run Utility tasks, Agent & Utility steps, findings, and feedback can be found in the Task Log.
7. The 3 panes on the left-hand side, right-hand side, and to the bottom of the Macro Canvas can all be collapsed and expanded as desired. This can be done by clicking on the icons with the double caret symbol.

Macros Tab

Next, we will dive a bit deeper into a macro:

1. The macro named “Customers from Shipments” is selected on the Macros tab on the left-hand side panel of DataStar. Clicking on a macro in the Macros tab will also open it in the macro canvas.
2. The macro has been expanded, so we see the list of tasks that are part of this macro. Users will note that:
   
   1. By default, each macro has a task named Start, which has its own specific icon and blue color. This task cannot be removed or renamed and the first actual task of the macro will be connected to it.
   2. Tasks from the Data Transfer category have light blue icons associated with them, and those from the Automate & Execute category are green. The icon itself also indicates the type of task it is. For example, the “Import Raw Shipments” task is an Import task from the Data Transfer category, and the “Create Unique Customers” task is a Run SQL task from the Automate & Execute category.
   3. Right-clicking on a Macro or a Task will bring up a context menu which can be used to Rename or Delete the Macro or Task. For tasks there is the extra option of Zoom to Task which will re-position the macro on the Macro Canvas such that this task is in the center.
3. Use the Search text box to quickly find a macro/task whose name contains the typed text.
4. This button can be used to expand or collapse all macros with one click.
5. Click on the Create Macro button in the toolbar to add a new Macro to the project.

Macro Canvas

The Macro Canvas for the Transportation Policies macro is shown in the following screenshot:

1. The tab tells us which macro we are looking at. Note that multiple macros/connection tables can be opened here in multiple tabs and users can easily switch between them by clicking on the tab of the desired macro/table.
2. The canvas currently shows 5 of the tasks that are part of the "Transportation Policies" macro. The bottom part of a task contains the name and the top colored part of a task shows what type of task it is. For example:
   
   1. The task at the top connected to Start is an Import task ; its name is “Import Shipments”.
   2. The task to the right of the "Import Shipments" task is a Delete task ; its name is “Delete Shipments before 2025”.
3. Tasks can be dragged and dropped onto the canvas from the Tasks list in the right-hand side pane. When hovering over the canvas, DataStar will suggest which task to chain the new task to based on proximity. If the task is dropped, it will automatically be connected to this suggested task. If the task is dropped onto the canvas without connecting to a task, the user can manually connect tasks by clicking in the middle of the right edge of the first task, holding the mouse down, and then clicking in the middle of the left edge of the next task. Please note that:
   
   • DataStar helps users by showing a bigger circle when hovering over the middle of a left or right edge of a task.
   • Tasks can be connected to multiple other tasks. If there are for example 2 tasks connected to a third task that succeeds the first 2, then this third task will not execute until both preceding tasks have completed.
   • To delete a line that connects 2 tasks: click on the line (it will then become a dotted line), and then hit the Delete or Backspace key. Alternatively, right-click on the line and select Delete from the context menu that comes up.
4. In the left bottom corner of the canvas users have access to the following controls, from top to bottom:
   
   • Zoom in: clicking on this plus icon will increase the size of the tasks on the canvas, less of the total macro will be visible.
   • Zoom out: clicking on this minus icon will decrease the size of the tasks on the canvas, more of the total macro will be visible.
   • Fit view: clicking on the icon with 4 square corners will set the position and zoom-level of the canvas such that all tasks that are part of the macro will be shown on the canvas, using up as much of the canvas space as possible.

5. The grey rectangle at the right bottom of the canvas is the "Mini Map", it shows a small diagram of where all the tasks that are part of the macro are positioned. The smaller white rectangle within this grey rectangle indicates which part of the entire macro the canvas is showing currently. This is helpful when you have a macro with many tasks and you want to pan through it while it is zoomed in.

‍

In addition to the above, please note following regarding the Macro Canvas:

1. Users can position the canvas as they desire by clicking on it, holding the mouse down and then moving the mouse to drag the canvas in any direction.
2. Users can also zoom in/out on the canvas by using the mouse or 2 fingers on a trackpad (move closer to each other to zoom out and move further apart to zoom in).
3. Clicking on a task in the canvas does several things:
   
   1. Selects the task (i.e. highlights it) in the macro(s) it is part of in the Macros tab on the left-hand side pane.
   2. Opens the Configuration of the task in the right-hand side pane.
4. Hovering over a task will make Run Task, Dupplicate Task and Delete icons visible:

• When clicking on the Run Task icon, the task is run by itself immediately. Its progress can be monitored in the Task Logs tab at the bottom of the macro canvas and in the Run Manager application on the Optilogic platform.
• Use Duplicate task to create an exact copy of the task in the same macro. The name of the copied task will be the original task's name appended with (1), (2), etc.
• After clicking on the Delete Task icon, a confirmation message to ensure the user wants to delete the task will come up first before the task is removed.

Tasks Tab

We will move on to covering the 2 tabs on the right-hand side pane, starting with the Tasks tab. Keep in mind that in the descriptions of the tasks below, the Project Sandbox is a Postgres database connection. The following tasks are currently available:

From top to bottom:

1. Import: import data from one data source into another. Data can be imported from a CSV, Excel, Cosmic Frog or Postgres database connection (in this case this does not include the Project Sandbox) into a Cosmic Frog or Postgres database connection. Typically used to import data from other connections into the Project Sandbox. This Quick Start Guide shows the Import task in action.
2. Export: export data from one data source into another. Data can be exported from a Cosmic Frog or Postgres database connection to another Cosmic Frog or Postgres database connection or to a CSV-file. Typically used to export data from the Project Sandbox into the connection that will hold the result of the DataStar workflow, such as a Cosmic Frog model. An example of using the Export task is shown in this Quick Start Guide.
3. Select: create a new table from a subset of columns and/or rows from one or multiple tables in a data connection, subject to easily configurable no-code joins and conditions.
4. Group By: create a new table by aggregating data from 1 or multiple tables in a data connection, subject to easily configurable no-code joins, grouping & aggregation statements, and optional pre- and post-aggreation conditions.
5. Run SQL: perform SQL queries on data in Cosmic Frog or Postgres database connections. Users can manually create their RunSQL tasks or use Leapfrog to create them. For the latter, please see this Quick Start Guide for more details.
6. Delete: delete all or a subset of records from a table in a Cosmic Frog or Postgres database connection.
7. Update: modify data in a table in a Cosmic Frog or Postgres database connection. Users can manually create their Update tasks or use Leapfrog to create them. This Quick Start Guide covers how to configure Update tasks.
8. Run Utility: within a Run Utility task, users can choose from a list of Utilities, specify any required parameters, and then add it as a task to incorporate into their Macro's workflow. Please see the AI Agents and Utilities - Overview article for more information on which agents and utilities are available and how to configure them. Actions that can be performed by using the Run Utility task for example include running a macro, duplicating macros & tasks, swapping connections, running geocoding or the integrity checker on a Cosmic Frog model.
9. Run Macro: run a macro from within the same DataStar project as part of anothe rmacro.
10. Run AI Agent: within a Run AI Agent task, users can choose from a list of AI Agents, specify any required parameters, and then add it as a task to incorporate into their Macro's workflow. Please see the AI Agents and Utilities - Overview article for more information on which agents and utilities are available and how to configure them. Workflows that can be performed by using the Run AI Agent task for example include profiling and cleansing data, building a Cosmic Frog model, analyzing model outputs and generating a report, and running FTL / LTL / Air Express Freight costing workflows.
11. Run Machine Learning: there are 4 types of analysis a Run Machine Learning task can do on a set of data: regression, classification, geographic clustering and clustering.
12. Run Python: execute a Python script as part of the data workflow in a macro.
13. Solve Model: run Cosmic Frog scenario(s) as part of your workflow.

Users can click on a task in the tasks list and then drag and drop it onto the macro canvas to incorporate it into a macro. Once added to a macro, a task needs to be configured; this will be covered in the next section.

Configuration Tab of a Task

When adding a new task, it needs to be configured, which can be done on the Configuration tab. When a task is newly dropped onto the Macro Canvas its Configuration tab is automatically opened on the right-hand side pane. To make the configuration tab of an already existing task active, click on the task in the Macros tab on the left-hand side pane or click on the task in the Macro Canvas. The configuration options will differ by type of task, here the Configuration tab of an Import task is shown as an example:

1. We are on the Configuration tab on the right-hand side pane in DataStar.
2. The type of task is shown here, in this case it is an Import task from the Data Transfer category.
3. The name of the task can be entered/updated here.
4. The Data Connection section needs to be configured:
   
   1. For each section within a task configuration, there is an indicator telling user the status of this section of the configuration. Here the green check mark indicates the Data Connection section of the task configuration has been completed. When this icon is orange, it means the configuration is not yet finished.
   2. Sections within a configuration can be expanded/collapsed by clicking on the down/up caret icon.
5. Within the Data Connection configuration section, first the Source is specified:
   
   1. Select the connection that will function as the source for the import task from the drop-down list containing the data connections set up in the project. Cosmic Frog, Postgres database, Excel, and CSV File connections can be used as the source for an Import task. Clicking on the plus icon to the right allows users to create a new data connection from within the task configuration tab.
   2. For data connections with multiple tables (such as a Cosmic Frog model), users can select the table to use as the source from the drop-down list, which also shows how many records each table contains. In our example here, we are using the Shipments connection, which is a CSV file, so the 1 table in this file is used and users do not need to select anything from the drop-down list. Clicking on the grid icon to the right will open the selected table in the central part of DataStar.
6. Next, the Destination of the import task is configured:
   
   1. Select the connection that will function as the destination for the import task from the drop-down list. This list will contain the available Postgres database connections (including the Project Sandbox and Cosmic Frog models). Oftentimes, the Project Sandbox will be the destination connection for Import tasks as the imported data will almost always still need to be cleansed, validated, and blended before reaching its final state. Again, the plus icon will let a user create a new data connection.
   2. Data can be imported into either a new or an existing table in the Destination connection. Choose the applicable option from the drop-down.
   3. If "New Table" was selected in the previous step, then enter the name of the new table that will be created in the destination data connection. If "Existing Table" was selected, choose the table to import the data from the Select Table drop-down list. Search, filter, and sort options are available to quickly find the desired table.
7. If an existing table was chosen as the destination for the import, then the source and destination columns need to be mapped to each other in the Data Mapping section. For more details on the Data Mapping section see this Quick Start Guide.
8. In the Run Configuration section, the resource size to be used when executing the Macro can be selected. This section is part of the configuration for all task types. Users can select the resource size they want to use for the task from the drop-down list and a link to this Help Center article which explains the different resource sizes is available from within this section too:

Please note that:

• The table name is set to RawShipments in the configuration, and it will be imported to the Project Sandbox as a table named rawshipments, so the name is converted to all lowercase.
• If there are spaces in the column names in the CSV file, these will be replaced by underscores when importing into the Project Sandbox. Special characters like parentheses in column names are removed. For example a column named Distance (MI) is imported as distance_mi.

The following table provides an overview of what connection type(s) can be used as the source / destination / target connection by which task(s), where PG is short for a PostgreSQL database connection and CF for a Cosmic Frog model connection:

Leapfrog Tab

Leapfrog in DataStar (aka D* AI) is an AI-powered feature that transforms natural language requests into executable DataStar Update and Run SQL tasks. Users can describe what they want to accomplish in plain language, and Leapfrog automatically generates the corresponding task query without requiring technical coding skills or manual inputs for task details. This capability enables both technical and non-technical users to efficiently manipulate data, build Cosmic Frog models, and extract insights through conversational interactions with Leapfrog within DataStar.

Note that there are 2 appendices at the end of this documentation where 1) details around Leapfrog in DataStar's current features & limitations are covered and 2) Leapfrog's data usage and security policies are summarized.

1. Leapfrog can be accessed by clicking on the “Ask Leapfrog AI” button in the toolbar at the top of DataStar. When you are already in Leapfrog and on the Leapfrog tab, clicking on this button again will start a new conversation.
2. A panel with two tabs will be opened to the right of the panel that contains the Tasks and Configuration tabs (which will be minimized upon opening Leapfrog):
   
   1. Previous Leapfrog conversations can be accessed from the Conversations tab.
   2. The current conversation will be shown in the Leapfrog tab, which will by default be the tab that is shown when opening Leapfrog.
3. The two tabs are by default opened so that 1 of the 2 is shown, and you can switch between them by clicking on the tabs at the top. Clicking on this icon will change the view to a split one, where both tabs are open side-by-side.
4. To close the Leapfrog panel, click on the cross at the right top.
5. When starting a new conversation, Leapfrog will show a welcome message with a short description of what it is, what is new in Leapfrog, and links to helpful resources.
6. This is the prompt writing area, where a user can indicate in natural language what they would like Leapfrog to do. The text prior to typing into the prompt indicates users can type an @ to get help with identifying tables and columns they may want to use in their prompt. This will be shown in screenshots further down in this section.
7. Once a prompt has been written, click on the send icon to submit it to Leapfrog.

1. The user has typed and submitted a prompt asking Leapfrog to create unique customers from the destination stores that are present in the rawshipments table (a table in the Project Sandbox) where only shipments between certain dates are to be used. Instructions to average the latitude and longitude are given in order to calculate a latitude and longitude for each customer.
2. While Leapfrog is working on its response, first a "Leapfrog is on it!" message will be shown, followed by updates summarizing Leapfrog's current internal process step.
3. The prompt area also indicates that Leapfrog is currently working on a response, so the next prompt cannot yet be submitted. Note however that you can start a new conversation or go back to an existing one and submit a prompt in there. This newly submitted prompt will then be processed in parallel with the earlier submitted prompt. Further below in this section it is explained how a new conversation can be started.

Leapfrog’s response to this prompt is as follows:

1. The prompt submitted by the user is listed at the top.
2. Leapfrog first describes in natural language what it has done in response to the prompt in the Documentation box.
3. It has created a Run SQL task in response to the prompt.
4. The Data Connection section lists that the target connection is the Project Sandbox.
5. In the SQL Script section, the SQL query that will be executed if adding this task as a Run SQL task to the macro is shown.
   
   1. User can click on this expand icon to show the SQL Query in a bigger Code Editor window. The complete SQL Query reads:

DROP TABLE IF Exists customers;
CREATE TABLE customers AS
SELECT  
  destination_store AS customer,  
  AVG(destination_latitude) AS latitude,  
  AVG(destination_longitude) AS longitude
FROM rawshipments
GROUP BY destination_store

6. The Notes section repeats the contents of the documentation box (see bullet 2 above), with an indication of how long the response took, and a summary of the number of characters and words. This will be added as Notes to the new task if it is is added to the Macro.
7. Users can provide feedback by clicking on the thumbs-up (positive) or thumbs-down (negative) icons. This way users can indicate if the Leapfrog created task was what they were expecting or not and the AI can be further improved by learning from the feedback.
8. Clicking on the “Add to Macro” button will add a task with this configuration to the Macro Canvas.

To help users write prompts, the tables present in the Project Sandbox and their columns can be accessed from the prompt writing box by typing an @:

1. The user has started typing their prompt and uses the @ character to get help with specifying a specific column in a specific table in their project sandbox.
2. Once the @ has been typed, a list with the tables currently present in the project sandbox comes up.
3. You can go through this list using the up and down arrow keys on your keyboard or you can click on the table you want to select. Once the table of your choice is selected, you can use the Enter key to close the list. This way you have selected a table without specifying a specific column in it. If you want to select a specific column in the table, use the right arrow key when you are on the table of your choice:

1. The user has selected the rawshipments table, which is now written in the prompt.
2. Using the right arrow key, the list has now changed to show the columns present in the rawshipments table.
3. You can again use the up and down arrow keys to go through the list, and hit the Enter key when on the column you want to select.

This user used the @ functionality repeatedly to write their prompt as follows, which helped to generate their required Run SQL task:

Now, we will also have a look at the Conversations tab while showing the 2 tabs in Split view:

1. We have clicked on the icon at the top left to change to Split view.
2. There are 3 Leapfrog conversations here. Clicking on one of them will open it up in the Leapfrog tab on the right-hand side where users can review their prior prompts and Leapfrog responses, add any tasks they had not added yet to their macro, or continue the conversation by submitting follow-up prompts.
3. Right-clicking on a conversation brings up a context menu with options to: 1) rename the conversation (by default its name is the text of the first prompt in the conversation), and 2) delete the conversation (the user will get a confirmation message before the conversation is deleted).
4. A Search box is available for users to type text into to quickly filter for conversations containing the search text in their name.
5. Use the Sort functionality to sort conversations chronologically of when they were created or alphabetically. Clicking again on the same sort option will reverse the order.
6. The "New Conversation" button can be used to start a new blank conversation.

Within a Leapfrog conversation, Leapfrog remembers the prompts and responses thus far. Users can therefore build upon previous questions, for example by following up with a prompt along the lines of “Like that, but instead of using a cutoff date of August 10, 2025, use September 24, 2025”.

Additional helpful DataStar Leapfrog links:

• This Quick Start guide on using Leapfrog to create a task from natural language walks through a similar example as the one above in detail and also contains a section with tips on how to write successful prompts.
• This DataStar Leapfrog Prompt Library contains example prompts which will likely spark ideas on what Leapfrog is capable of and help users get more out of Leapfrog in DataStar.

Running a Macro

Users can run a Macro by selecting it and then clicking on the green Run button at the right top of the DataStar application:

1. The “Customers from Shipments” macro is open and is also selected in the Macros tab on the left-hand side pane (not shown).
2. The green Run button is enabled and clicking this will immediately kick off the macro run. Its progress can be monitored in the Macro Logs tab at the bottom of the macro canvas (see also next section) and in the Run Manager application on the Optilogic platform.

Please note that:

• If a task is selected in the Macros tab on the left-hand side pane or is selected in the macro canvas by clicking on it, then clicking on the Run button will bring up following message where the user can choose to run the whole macro the task is part of or just the task by itself:

• An individual task can also be run by hovering over it or selecting it by clicking on it, and then clicking on the play button that has become visible.
• Macros do not need to be complete to be run, it is good practice to run individual tasks and partially completed macros before completely building out a macro without testing it along the way.

When a macro/task is running, the tasks on the macro canvas have visual indicators of the status of the run, while the Macro Logs and Task Logs tabs at the bottom also contain information on the runs, see the next section.

Macro and Task Logs Tabs

Macro Logs

Next, we will cover the Logs tabs at the bottom of the Macro Canvas where logs of macros/tasks that are running/have been run can be found:

When a macro has not yet been run, the Macro Logs tab will contain a message with a Run button, which can also be used to kick off a macro run. When a macro is running or has been run, the macro log will look similar to the following:

1. The pane at the bottom of the macro canvas is expanded and we are on the Macro Logs tab.
2. At the top of the log the name of the macro is listed. If the user switches to a different macro in the macros tab or by clicking on a tab at the top of the macro canvas, the Logs tab will display the logs of that newly selected macro.
3. The Total Run Time indicates how long the macro ran for (if completed) or has been running for so far (if still processing).
4. In the Run Selection drop-down, users can switch between looking at the logs of the current macro run and any previous runs of this particular macro.
5. If a Macro is still running, the Cancel Macro button can be used to abort the run.
6. The run summary indicates how many of the total number of tasks that were attempted to be run (the "All" number):
   
   • Errored - did not run to completion.
   • Are Blocked - if a task is dependent on preceding task(s), it is blocked until the preceding task(s) have completed successfully.
   • Are Pending - awaiting to be run.
   • Are Processing - are currently being executed.
   • Have Completed - have finished running without any errors.
7. The macro that was run (Customers from Shipments) has 3 tasks, Import Raw Shipments, Create Unique Customers, and Export Customers to CF Model. We see in these 3 log records that the first task has completed successfully, the second task is pending and should start processing shortly, and the third task is blocked as it is dependent on the second task completing successfully. The type of task, and when the task started and ended are listed too. Should error(s) have occurred, the last one recorded will be listed in the Last Error column.
8. This grid and its columns can be customized by the user, see the Appendix for details.

The next screenshot shows the log of a run of the same macro where the third task ended in an error:

1. For the run we are viewing the log for, the status bar indicates that 1 task errored.
2. Looking at the records in the grid, we see that the third task has status errored.
3. For this third task the last error that was encountered during the execution of the task is listed in the Last Error column. If the entire error is not visible, you can hover over it and the full text will be shown in a pop-up text box. Reading this last error may help a user pinpoint the problem, but if not, our dedicated support team can most likely help! Feel free to reach out to them on support@optilogic.com.

Please note that:

• A log is recorded in the Macro Logs tab while a macro is running, users can watch the real-time updates if the Macro Logs tab is open.
• No log is available for a macro that has not yet been run.

Task Logs

For the following supported tasks a task log is generated when the task is run: Import, Export, Run Utility, Run AI Agent, Run Machine Learning, Run Python, and Solve Model. An example is shown in the next screenshot for a Run AI Agent task using the Data Cleansing AI Agent:

Data Connections Tab

In the Data Connections tab on the left-hand side pane the available data connections are listed:

1. User has clicked on the Data Connections tab in the left-hand side pane of DataStar to make this the active tab.
2. In the top part of the connections list, the Active and Bookmarked Connections are listed; by default the list is expanded. Active means the connection is used by 1 or more tasks in any of the macros of the currently open project. Users can manage which connections are bookmarked themselves by adding and removing bookmarks., see also further below in this section on how to do this. Connections can be expanded to view their content (e.g. the tables/views contained in them) by clicking on the caret icon to the left of the connection's name. See the next screenshot for what the connections list looks like when the connections are expanded.
   
   1. Active connections are indicated with this green checkmark icon.
   2. Bookmarked connections are labeled with this blue icon. Bookmarks are project-based: a bookmarked connection in 1 project is not automatically bookmarked in other DataStar projects.
3. All other Data Connections currently set up within DataStar are listed in the All Connections list, which is also expanded by default. With the exception of the Project Sandbox, which is unique to each project, all connections are accessible by all DataStar projects.
4. To quickly find specific connections and/or tables contained in them, users can type into the Search box. Connections and tables with the search text in their names will be filtered out and shown in the list. Please note that for the search to be performed on tables within a data connection, the data connection needs to be expanded (see previous bullet). If the option to not show empty tables is enabled (next bullet), then the search will also not search these empty tables and only return populated tables.
5. Clicking on the filter icon will bring up 2 options for what is included when showing the contents of connections:
   
   1. Show Empty Tables - the user can choose to show these in the tables list when the connection is expanded by leaving the checkbox enabled (default) or, alternatively, disable this checkbox so that empty tables are hidden.
   2. Show Views - database connections can have views in them, which are named queries that run on 1 or multiple tables in the database. By default this checkbox is unchecked and views are not shown when a connection is expanded. However, users can choose to show them by enabling this checkbox.

Next, we will have a look at what the connections list looks like when some of the connections have been expanded:

1. The Project Sandbox connection, which is a Postgres database underneath, has been expanded:
   
   1. There are multiple schemas present in the Project Sandbox database; the one that contains the tables and will be shown when expanded is the Starburst schema.
   2. We see that there are 2 tables here which have been populated by running the Customers from Shipments macro: the rawshipments table is the result of the Import task ("Import Raw Shipments") in the macro; it has 42.66k records. The customers table is the result of running the Run SQL task ("Create Unique Customers") and this has resulted in 1.33k unique customers.
2. The Historical Shipments connection is the CSV File data connection connected to the shipments.csv file which contains raw shipment data. Since it is a CSV File connection, it has 1 table in it, which has the same name as the csv file it is connected to (shipments).
3. This Cosmic Frog model connection is named Global Dairy E2E. Cosmic Frog models are also Postgres databases underneath with a specific schema that Optilogic's Cosmic Frog application uses for optimizations (including network and transportation), simulations (including inventory), and Greenfield runs.
   
   1. The schema used for the tables in a Cosmic Frog model is called anura_2_8 and this schema is expanded in the connection to view the tables.
   2. In this example, we have chosen not to show empty tables and we see the first 10 populated tables in the list.
4. In this screenshot, showing empty tables has been turned off using the filter option at the right top of the tab. The blue dot at the right top of the filter icon gives a visual indication that a filter is applied.

Right-clicking on a connection brings up the following context menu:

1. Use the Refresh option to view the connection's most recent data.
2. If a connection is already bookmarked, an option to remove the bookmark is available. For connections that are not bookmarked, the option here is to bookmark the connection.
3. An option to Delete the connection is available too. This removes the connection from all DataStar projects, also when it is in use (active) in any other project.

Right-clicking on a table in a connection also brings up a context menu:

1. Use the Export to CSV option to create a CSV file containing the contents of the table. The CSV file will be available for download from https://optilogic.app/#/user-downloads; a new browser tab with this page will automatically open.
2. For Cosmic Frog model connections, Postgres database connections, and the Project Sandbox, users have the option to open them in SQL Editor. Clicking on this option opens a new browser tab with the selected database open in SQL Editor.
3. For tables in the Project Sandbox, users have the option to drop them (remove them). This is especially useful when testing out a macro that is in development: before re-running the updated macro, the user may want to drop any tables the macro creates.

Viewing a Connection's Table

The tables within a connection can be opened within DataStar. They are then displayed in the central part of DataStar where the Macro Canvas is showing when a macro is the active tab.

Please note:

• Currently, a data preview of up to 10,000 records for a table is displayed for tables in DataStar. This means that any filtering or sorting done on tables larger than 10k records is done on this subset of 10k records. At the end of this section it is explained how datasets containing more than 10k records per table can be explored by using the SQL Editor application.
• Since the Excel data connection is currently in its beta version, data previews are not yet available for it.

1. A table is opened in the central part of DataStar by clicking on it in the connections list. Here the user clicked on the rawshipments table to open it. The tabs across the top of the central part where the table is now displayed have the name of the table or macro that is open in that tab on them. Users can switch between tables and macros by clicking on the tabs. Currently, the rawshipments table and the "Customers from Shipments" macro are both open, with the rawshipments table being shown since that is the active tab.
2. At the moment, DataStar will show a preview of up to 10,000 records of any table. The total number of records in the table is also mentioned here. As mentioned above, this also means that any filtering or sorting is performed on this subset of up to 10k records.
3. An additional menu named Table Functions is available in the toolbar when a table is open in DataStar's central part. Options from this menu are:
   
   1. Export to CSV - this will export the table to a csv file which will be accessible from user's Downloads area on the Optilogic platform (click on your username at the right top of the screen and select Downloads from the drop-down list). Note to check back in a few minutes if you do not see the download there immediately.
   2. Open in SQL Editor - for databases, this will open the database in the SQL Editor application on the Optilogic platform and show the table that was active in DataStar. A screenshot of a DataStar project sandbox database in SQL Editor and a link to a Help Center article on the SQL Editor application are included at the end of this section.
4. This grid can be customized by the user (e.g. sort and change the order of columns), see the appendix on how to do this.
5. Users can also filter the grid based on values in one or multiple columns. The next screenshot covers this in more detail.
6. On the right-hand side, there are 2 panes available that will become visible when clicking on their names: 1) Columns: to configure which columns are shown in the grid and in which order, and 2) Filters: filters can also be configured from this fold out pane. Each of these are covered in a screenshot further below in this section. Once a pane has been opened, it can be closed again by clicking on its name on the right-hand side of the pane once more.

A table can be filtered based on values in one or multiple columns:

1. A column that has been filtered can be recognized by the blue filter icon to the right of the column name. This filter icon is black when not filtering on this column. Clicking on the filter icon brings up a form where filters can be configured.
2. Currently, the origin_dc field is filtered for records where the value contains the text "dallas". This is non-case sensitive and all records that have "dallas" in their name (whether at the start, at the end or somewhere in between) will be filtered out and shown. Please note that:
   
   • Once a user hits the Enter key after typing into the Filter... text box, the filter is applied.
   • To remove a filter, users need to delete the text from the Filter... text box.
3. A filter can consist of multiple parts and whether only records that satisfy all filter parts are shown or records that satisfy at least one of the parts are shown depends on the selection of "AND" vs "OR" here. When using AND, only records that satisfy all filter parts will be shown. When using OR, records that satisfy at least one of the filter parts will be shown.
4. Besides filtering records for their values containing certain text (see bullet 2 above), there are additional options available as shown in this drop-down list. After selecting the desired option, user can type in the Filter... text box (not visible in the above screenshot as it is covered by the filter type drop-down list). The drop-down list shown in the above screenshot is for columns of string/text data type. Different options are available for columns containing numerical data, as shown here for the Units column:

Columns can be re-ordered and hidden/shown as described in the Appendix; this can be done using the Columns fold-out pane too:

1. Click on Columns on the right-hand side of the table to open the Columns pane.
2. To find the column(s) of interest quickly, users can type into the Search... text box to filter the list of columns down to those containing the typed text in their name.
3. These checkboxes are used to hide/show columns in the grid: uncheck a column's checkbox to hide it. Note that the checkbox at the top of the list can be used to hide/show all columns with one click.
4. The order of the columns in the grid can be changed by clicking on the icon with 4x3 dots, then hold the mouse down and drag the column up or down. Let go of the mouse once the column is in the desired position.

Finally, filters can also be configured from a fold-out pane:

1. Click on Filters on the right-hand side of the table to open the Filters pane.
2. To find the column(s) you want to filter on quickly, you can type into the Search... text box to filter the list of columns down to those containing the typed text in their name.
3. Click on the caret icon to the left of the column name that you want to apply the filter to so that it expands and the filter configuration for the column becomes visible. Configure the filter as covered above by selecting the filter type from the drop-down and typing the filter criterion into the Filter... text box.
4. A column that has a filter applied to it already can be recognized in the list: it has a filter icon to the right of its column name whereas unfiltered columns have no such icon displayed.

Users can explore the complete dataset of connections with tables larger than 10k records in other applications on the Optilogic platform, depending on the type of connection:

• Lightning Editor: for CSV files
• SQL Editor: for Postgres DB connections, which includes the Project Sandbox and Cosmic Frog models. See this SQL Editor Overview help center article on how to use the SQL Editor. For the Project Sandbox, please note that:
  
  • The name of the Project Sandbox database is the same as the project name
  • The tables that are created in the sandbox can be found under the “starburst” schema

Here is how to find the database and table(s) of interest in SQL Editor:

1. When logged into the Optilogic platform, click on the SQL Editor icon in the list of available applications on the left-hand side to open it. Your SQL Editor icon may be in a different location in the list, and if it is not visible at all, then click on the icon with 3 horizontal dots to show any applications that are not shown currently.
2. Either use the Search box at the top to find your database of interest or scroll through the list. DataStar project sandbox databases can be recognized by the DataStar logo to the left of the database name. The name of a DataStar project sandbox database is that of the DataStar project it belongs, in our example "Import Historical Shipments".
3. When expanding the database, the starburst schema which contains the tables contained in the data connection will by default be expanded too.
4. We see the customers and raswhipments tables that were the result of running the Customers from Shipments macro. Clicking on a table will run a query to show the first 20 records of that table.

Helpful Resources

Here are a few additional links that may be helpful:

• Additional DataStar documentation on Optilogic's Help Center can be found in this Navigating DataStar section.
• Frequent Optilogic’s Frogger Pond community portal to connect with other DataStar users.
  

We hope you are as excited about starting to work with DataStar as we are! Please stay tuned for regular updates to both DataStar and all the accompanying documentation. As always, for any questions or feedback, feel free to contact our support team at support@optilogic.com.

Appendix - Customizing Grids

The grids used in DataStar can be customized and we will cover the options available through the screenshot below. This screenshot is of the list of CSV files in user's Optilogic account when creating a new CSV File connection. The same grid options are available on the grid in the Logs tab and when viewing tables that are part of any Data Connections in the central part of DataStar.

1. The columns in the grid can be dragged to change the order of the columns, and they can also be resized by clicking on the vertical bar in between the columns (the mouse then changes to 2 arrows pointing away from each other), holding the mouse down and moving right or left. Double-clicking while hovering over the vertical bar (mouse has changed to 2 arrows pointing away from each other) will autosize the column to fit the longest value.
2. The grid can be sorted by the values of a column by clicking on its column name; this will sort the column in ascending order. Clicking on the column name will change the sort to be in descending order and clicking a third time takes the sort off the column. Sorting by multiple columns is possible too: sort the first column as desired, then hold down the Ctrl and Shift keys while clicking on the name(s) of a second, third, etc. column to add them to the multi-sort. Numbers indicate the order of the sort. Here, the grid was first sorted by the Location column and then by File Name.
3. Clicking on the icon with 3 vertical dots to the right of a column name will bring up a context menu with the following options:
   
   • Sort Ascending / Sort Descending / Clear Sort: depending on if the column is sorted and if so, how, 2 of these 3 options will be listed for each column to quickly change / take off the sort on this column.
   • Pin Column: columns can be put in a fixed position that will stay visible when scrolling. Options are to pin the column all the way to the left or all the way to the right of the grid.
   • Autosize This column: change the width of the column to fit the longest value.
   • Autosize All Columns: change the width of all columns in the grid to fit their longest values.
   • Choose Columns: brings up the list of columns present in the grid with the options to 1) hide them by unchecking their checkboxes and / or 2) change the column order by dragging columns to different positions in the list.
   • Reset Columns: unhides all columns if any are hidden and puts them in their original order.

Appendix - Leapfrog Features & Limitations

Current Version Features:

• Text to SQL generation capabilities through Run SQL and Update tasks. Currently, the following types of SQL queries are supported:
  
  • Insert
  • Update
  • Delete
  • Drop Table
  • Create Table
  • Alter Table
  • Union
• Supported data connections: Project Sandbox (Starburst schema) relevant to the DataStar project. Use the @ character in prompts to let Leapfrog help you with the table and column names.

• Output formats - each prompt response typically contains:
  
  • Description on what Leapfrog creates in the Documentation part
  • Run SQL or Update task
  • Add to Macro option
  • Notes section which repeats the documentation text, plus an indication of how long the response took, and the number of characters and words. This becomes the Notes section of the task if it is added to the macro.
• Multi-turn conversation: Leapfrog has a ‘memory’ within each conversation. This means users can reference a previous prompt or response in a subsequent request.
• Conversation history is kept and user can go back to previous conversations to for example add any tasks to a macro that were not added yet or continue a conversation from where it was left off.
• Multiple conversations can be working on a prompt response simultaneously.
• Multi-language support: users can submit their prompt in languages other than English, and the Documentation part of the response will be in the same language.

Current Limitations

• Each task created from Leapfrog can only use 1 connection at a time, and this connection is the Project Sandbox (Starburst). Moving data from one connection to another is not yet supported.
• Leapfrog in DataStar cannot answer questions about its own capabilities yet.

Appendix - Leapfrog Data Usage & Security

Training Data

Leapfrog's brainpower comes from:

• Optilogic's Anura schema
• Hundreds of handcrafted SQL examples from real supply chain experts

All training processes are owned and managed by Optilogic — no outside data is used.

Using Leapfrog

When you ask Leapfrog a question:

• It securely accesses your data through an API.
• Your data stays yours — no external sharing or external training.

Conversation History

Your conversations (prompts, answers, feedback) are stored securely at the user level.

• Only you and authorized Optilogic personnel can view your history.
• Other users cannot access your data.

Privacy and Ownership

• You retain full ownership of your model data. Only authorized Optilogic personnel can access it.
• Optilogic uses industry-standard security protocols to keep everything safe and sound.

‍

‍

‍