Manufacturing DI Turning Data into ‘Decisions’: 10 Practical Exercises Connecting Orders, Quality, and Equipment

In this article, we will build a small manufacturing DI（Decision Intelligence: Decision Intelligence) using a fictional precision parts factory as the subject. By connecting orders, manufacturing performance, quality, and equipment downtime through a common data model, it not only detects KPI anomalies but also manages possible causes, future scenarios, recommended actions, and post-execution records as a single flow.

The target is No.091 to No.100. Rather than listing individual technologies, we explain according to manufacturing practices: “Which decisions to make, with which data and models, and who to execute safely?”

[!NOTE] This material is a notebook previously used by Surikoubo (or personally by the representative, Kazuyama), and has been reconstructed, edited, and published with the company’s permission.
All data listed is fictional and has no relation whatsoever to real companies, factories, or figures.

Introduction: Practical Challenges in Manufacturing Covered in This Article

The factory has systems for production management, quality control, equipment maintenance, and cost management. However, what we really want to know in meetings is not the individual system numbers, but rather questions like, “What caused this month’s missed delivery?” “Should recovery be achieved through overtime or outsourcing?” and “How measures affect gross profit and quality.”

Here, we address the challenge of determining the production policy for the following week by simultaneously considering the three lines producing precision valve components, including delivery deadlines, defects, stoppages, and marginal profit.

Common situations on site

• Creating KPI materials takes time, and the data is outdated at the time of the meeting.
• Definitions and aggregation granularity differ by department
• Even when abnormalities are found, the relationships between orders, equipment, and quality are manually traced.
• Simulations and optimizations stop on the analyst’s PC, leaving no execution history
• AI proposal reasons, reference data, and approvers cannot be tracked or deployed on site.

The goal of DI is not to add more dashboards. It aims to shorten lead times from observation to judgment, execution, and learning, thereby improving the reproducibility of decision-making.

Why is this issue so difficult to judge?

Decision-making in manufacturing involves a mix of multiple time axes and objectives. Increasing equipment utilization can increase short-term production volume, but it can lead to quality deterioration or postponed maintenance. Outsourcing to meet deadlines ensures sales while reducing marginal profit.

Furthermore, actual figures carry uncertainties such as demand fluctuations, downtime, and yields. Therefore, rather than maximizing a single KPI, it is necessary to design decisions that include causality, constraints, predictive distribution, and approval rules among KPIs.

Overview of Exercise covered this time

No.	Theme	Questions in this notebook
091	What is Manufacturing DI?	How to connect data to decisions and execution
092	KPI Design	How to connect business performance with frontline leading indicators
093	Data Model Design	How to securely combine data of different granularities
094	Ontology Design	How to standardize terminology and relationships
095	knowledge graph	How to trace possible causes from KPI anomalies
096	Simulation Platform	How to compare proposals under uncertainty
097	Optimization Platform	How to choose an action plan that adheres to constraints
098	Utilizing AI Agents	How to Incorporate Proposals into Secure Business Workflows
099	Design of the manufacturing version of Palantir	How to integrate data, models, and operations
100	The World Aimed for by Surikobo	How to foster a decision-making foundation for continuous learning

The further you go into the latter half, the Description (what happened)→Diagnosis (for some reason)→Prediction (what will happen)→Prescription (what to do)→Execution and Learning develops.

Preparing the Python environment

It does not rely on external data; it generates fictional data using numpy and pandas and visualizes it with matplotlib. The random number generator fixes the seed. networkx will be used for the knowledge graph in the latter half.

import platform
import sys

import japanize_matplotlib
import matplotlib
import matplotlib.pyplot as plt
import networkx as nx
import numpy as np
import pandas as pd
from IPython.display import display

SEED = 42
rng = np.random.default_rng(SEED)
pd.set_option("display.max_columns", 20)
pd.set_option("display.float_format", lambda x: f"{x:,.2f}")

print(f"Python      : {sys.version.split()[0]}")
print(f"OS          : {platform.system()} {platform.release()}")
print(f"numpy       : {np.__version__}")
print(f"pandas      : {pd.__version__}")
print(f"matplotlib  : {matplotlib.__version__}")
print(f"networkx    : {nx.__version__}")

Creation of Fictional Data

We create daily performance data by line for 90 days. The primary key is date × line_id. We assign demand, planning, production, good products, defects, stoppages, overtime, power, and quantities within delivery deadlines. The L3 line is set to have deteriorating downtime and defect rates over the last 45 days, intentionally embedding changes that DI should detect.

Marginal profit is simplified and is calculated by subtracting material costs, overtime costs, and electricity costs from good product sales. In practice, it is important to align with accounting definitions and avoid confusion between the allocation and the period before and after allocation.

dates = pd.date_range("2025-01-01", periods=90, freq="D")
lines = pd.DataFrame({
    "line_id": ["L1", "L2", "L3"],
    "line_name": ["cutting1number", "cutting2number", "Composite processing"],
    "rated_units": [128, 116, 104],
    "product_id": ["P-A", "P-B", "P-C"],
})
products = pd.DataFrame({
    "product_id": ["P-A", "P-B", "P-C"],
    "product_name": ["Standard Valve", "Heat-resistant valve", "high-pressure valve"],
    "price_yen": [8200, 10600, 14800],
    "material_yen": [3900, 5200, 7600],
})

rows = []
for day_no, date in enumerate(dates):
    weekday_factor = 0.90 if date.dayofweek >= 5 else 1.00
    for rec in lines.itertuples(index=False):
        demand = max(55, int(rng.normal(rec.rated_units * 0.91 * weekday_factor, 12)))
        planned = min(int(rec.rated_units * weekday_factor), demand + int(rng.integers(2, 11)))
        stop_mean = 42 if (rec.line_id == "L3" and day_no >= 45) else 24
        downtime = max(0, rng.normal(stop_mean, 10))
        overtime = max(0, demand - planned) * 0.12 + rng.uniform(0, 1.8)
        availability = np.clip(1 - downtime / 480, 0.70, 1.00)
        produced = max(0, int(planned * availability + overtime * 5 + rng.normal(0, 3)))
        defect_base = {"L1": 0.018, "L2": 0.025, "L3": 0.028}[rec.line_id]
        if rec.line_id == "L3" and day_no >= 45:
            defect_base += 0.025
        defective = rng.binomial(produced, min(0.15, defect_base + downtime / 12000))
        good = produced - defective
        on_time = min(good, max(0, int(demand - max(0, rng.normal(downtime / 18 - 1, 3)))))
        rows.append([date, rec.line_id, rec.product_id, demand, planned, produced,
                     good, defective, downtime, overtime, produced * rng.uniform(2.7, 3.3), on_time])

daily = pd.DataFrame(rows, columns=[
    "date", "line_id", "product_id", "demand_units", "planned_units",
    "produced_units", "good_units", "defect_units", "downtime_min",
    "overtime_h", "energy_kwh", "on_time_units"
]).merge(products, on="product_id", validate="many_to_one")
daily["sales_yen"] = daily["good_units"] * daily["price_yen"]
daily["contribution_yen"] = (
    daily["good_units"] * (daily["price_yen"] - daily["material_yen"])
    - daily["overtime_h"] * 3_200 - daily["energy_kwh"] * 24
)
daily["defect_rate"] = daily["defect_units"] / daily["produced_units"].clip(lower=1)
daily["otd_rate"] = daily["on_time_units"] / daily["demand_units"].clip(lower=1)

print(f"Daily Line Performance: {len(daily):,}rows / Period: {daily['date'].min().date()}〜{daily['date'].max().date()}")
display(daily.head())

No.091: What is Manufacturing DI — Turning Observation to Execution into a Single Decision Loop

Meaning in Practice

While BI visualizes “what happened,” DI connects that information to cause analysis, option evaluation, recommendations, approvals, execution, and effectiveness verification. In manufacturing, it is important not only to display red for missed deliveries, but also to identify the contribution of stoppages and defects, and to design whether to use overtime, maintenance, or outsourcing.

Approach to Analysis and Modeling

Place the smallest decision loop as Observe → Diagnose → Predict → Decide → Act → Learn. First, we aggregate the on-time delivery rate (OTD), defect rate, downtime time, and marginal profit at the same granularity for each line.

$$\mathrm{OTD}=\frac{\text{Quantity within delivery deadline}}{\text{Required quantity}},\qquad \mathrm{Defect\ rate}=\frac{\text{defective quantity}}{\text{production quantity}}$$

Check with Python

The most recent 30 days are considered the decision-making period, and multiple KPIs are compared on the same scorecard.

recent = daily[daily["date"] >= daily["date"].max() - pd.Timedelta(days=29)]
di_scorecard = recent.groupby("line_id").agg(
    demand=("demand_units", "sum"),
    good_quantity=("good_units", "sum"),
    quantity_on_delivery=("on_time_units", "sum"),
    production_volume=("produced_units", "sum"),
    number_of_defects=("defect_units", "sum"),
    stop_time=("downtime_min", "sum"),
    marginal_profit_circle=("contribution_yen", "sum"),
)
di_scorecard["On-time delivery rate"] = di_scorecard["quantity_on_delivery"] / di_scorecard["demand"]
di_scorecard["non_performing_rate"] = di_scorecard["number_of_defects"] / di_scorecard["production_volume"]
display(di_scorecard[["demand", "good_quantity", "On-time delivery rate", "non_performing_rate", "stop_time", "marginal_profit_circle"]])

ax = di_scorecard[["On-time delivery rate", "non_performing_rate"]].plot.bar(figsize=(8, 4), color=["#2a6fbb", "#d95f02"])
ax.set_title("most recent30By day lineDIScorecard")
ax.set_xlabel("Line")
ax.set_ylabel("ratio")
ax.grid(axis="y", alpha=0.3)
ax.legend(loc="best")
plt.tight_layout()
plt.show()

Reading the results

L3 has a lower on-time delivery rate and higher defect rates than other lines, and it has been confirmed that downtime is also significant. Since multiple KPIs are worsening simultaneously rather than a single red flag, diagnosis from the perspective of equipment and quality should be prioritized over simple production increases. In DI, this scorecard serves as the entry point for the next cause search and countermeasure comparison.

No.092: KPI Design — Breaking down management results into actionable metrics on the ground

Meaning in Practice

With just sales and profits, the field doesn’t know what needs to change today. On the other hand, chasing only the easily measurable utilization rate can lead to overproduction or postponed maintenance. It is necessary to connect lagging and leading indicators with causal hypotheses, and to define responsible persons and update frequencies.

Approach to Analysis and Modeling

Here, performance KPIs are defined as marginal profit and on-time delivery rate, while leading KPIs are defect rate, downtime rate, and overtime hours. Standardize achievement from goals in a directional way to create a weighted health score.

$$S=100\sum_k w_k a_k,\qquad \sum_k w_k=1$$

The higher the KPI, the $a_k=\min(x_k/t_k,1)$, and the smaller the better, the $a_k=\min(t_k/x_k,1)$. However, the overall score is the entry point for drill-down, and individual indicators should not be hidden.

Check with Python

kpi = di_scorecard.copy()
kpi["stop rate"] = kpi["stop_time"] / (30 * 480)
kpi["overtime hours"] = recent.groupby("line_id")["overtime_h"].sum()
kpi["Profit Achievement"] = (kpi["marginal_profit_circle"] / 12_000_000).clip(upper=1)
kpi["OTDachieve"] = (kpi["On-time delivery rate"] / 0.97).clip(upper=1)
kpi["Quality Achievement"] = (0.025 / kpi["non_performing_rate"]).clip(upper=1)
kpi["stop achievement"] = (0.07 / kpi["stop rate"]).clip(upper=1)
kpi["KPIhealth level"] = 100 * (
    0.35 * kpi["Profit Achievement"] + 0.30 * kpi["OTDachieve"]
    + 0.20 * kpi["Quality Achievement"] + 0.15 * kpi["stop achievement"]
)
display(kpi[["On-time delivery rate", "non_performing_rate", "stop rate", "overtime hours", "marginal_profit_circle", "KPIhealth level"]].round(3))

fig, ax = plt.subplots(figsize=(8, 4))
kpi["KPIhealth level"].sort_values().plot.barh(ax=ax, color=["#d95f02", "#e6ab02", "#1b9e77"])
ax.axvline(90, color="black", linestyle="--", label="Line of caution 90point")
ax.set_title("Management and On-siteKPIIntegrated health")
ax.set_xlabel("KPIHealth Level (0〜100）")
ax.set_ylabel("Line")
ax.grid(axis="x", alpha=0.3)
ax.legend()
plt.tight_layout()
plt.show()

Reading the results

The reason L3 health is low is not only OTD but also a combination of quality and failure to meet downtime targets. In practice, weights are not determined solely by analysts; instead, factory managers, manufacturing, quality, and maintenance agree on these points, and definitions, units, aggregation granularity, update frequency, responsible persons, and target values are recorded in the KPI ledger.

No.093: Data Model Design — Determining aggregation granularity and primary key first

Meaning in Practice

Orders are received by the item, manufacturing by the lot, equipment by the second, and quality by the inspection unit. If you combine these without checking the key, the rows multiply, and sales and defects are double-counted. A good data model supports the idea that “the same questions get the same answers” rather than just analysis speed.

Approach to Analysis and Modeling

Separate facts (achievements) from dimensions (attributes of products and equipment). The granularity of daily line performance is date × line_id × product_id, and the contract ensures that both the line master and the product master are unique. We also check whether the number of rows and total values are saved before and after merging.

Check with Python

fact = daily[["date", "line_id", "product_id", "good_units", "defect_units", "contribution_yen"]].copy()
dim_line = lines[["line_id", "line_name", "rated_units"]].copy()
dim_product = products.copy()

assert not fact.duplicated(["date", "line_id", "product_id"]).any()
assert dim_line["line_id"].is_unique
assert dim_product["product_id"].is_unique

model = (fact
         .merge(dim_line, on="line_id", validate="many_to_one")
         .merge(dim_product, on="product_id", validate="many_to_one"))
quality_contract = pd.DataFrame({
    "Inspection items": ["Fact Primary Key Overlap", "Difference in row count before and after joining", "Difference in the number of good products", "marginal profit difference"],
    "Results": [
        fact.duplicated(["date", "line_id", "product_id"]).sum(),
        len(model) - len(fact),
        model["good_units"].sum() - fact["good_units"].sum(),
        model["contribution_yen"].sum() - fact["contribution_yen"].sum(),
    ],
    "Passing Requirements": ["0", "0", "0", "0"],
})
display(quality_contract)
display(model.head(3))

Reading the results

All four test results were zero, confirming that there was no double counting due to dimension coupling. In practice, this inspection is automated during pipeline execution, and if violations occur, dashboard updates and optimization execution are halted. Rather than “just joining for now,” the starting point is to manage granularity and primary keys as data contracts.

No.094: Ontology Design — Making Business Terms and Relationships Machine-Readable

Meaning in Practice

Even with the same “stop,” if there are departments that include planned stoppages and those that do not, a comparison of meetings cannot be made. Ontology defines concepts and relationships such as equipment, products, KPIs, events, and countermeasures as common vocabulary, serving as a blueprint connecting data and operations.

Approach to Analysis and Modeling

The concept is represented in three pairs of subject―Relationships―object. The important thing is not to stay in the glossary, but to have relationships and constraints like The line produces the product., Downtime events occur on the equipment, and KPIis calculated from actual performance. The KPI formula and data history are placed in the same semantic layer.

Check with Python

triples = pd.DataFrame([
    ("L3", "type", "ProductionLine"),
    ("L3", "produces", "P-C"),
    ("P-C", "type", "Product"),
    ("DT-L3", "type", "DowntimeEvent"),
    ("DT-L3", "occursOn", "L3"),
    ("DT-L3", "affects", "Availability"),
    ("Availability", "contributesTo", "OTD"),
    ("DefectRate", "contributesTo", "OTD"),
    ("OTD", "calculatedFrom", "DailyLineFact"),
    ("MaintenanceAction", "mitigates", "DT-L3"),
], columns=["subject", "predicate", "object"])

ontology_summary = triples.groupby("predicate").size().rename("relationship number").to_frame()
display(triples)
display(ontology_summary)

Reading the results

From L3 downtime events to availability, OTD, and security measures, the relationship was expressed as a common one. This allows you to search for “which KPIs the pause will affect even if the screen or table name changes.” In practical implementation, instead of creating company-wide vocabulary all at once, we start with concepts necessary for a single decision, such as restoring deadlines, and manage the layout while preserving the language of the field.

No.095: Knowledge Graph — Tracing Causes and Countermeasures from KPIs

Meaning in Practice

Conducting operations that ask experts every time KPIs are abnormal becomes dependent on individuals and lengthens the investigation time. The knowledge graph traces the relationships among equipment, events, KPIs, causes, and countermeasures, supporting the initial diagnosis response. However, the path is not a proof of causality, but an investigative hypothesis.

Approach to Analysis and Modeling

If ontologies are blueprints of meaning, knowledge graphs store specific objects and relationships. Search for sources of impact from abnormal KPIs in reverse and connect to countermeasure candidates. You can prioritize candidates with short graph distances, but separate time series consistency and statistical verification are performed.

Check with Python

edges = [
    ("spindle wear", "non_performing_rate", "increases"),
    ("spindle wear", "sudden stop", "causes"),
    ("sudden stop", "availability", "decreases"),
    ("availability", "On-time delivery rate", "decreases"),
    ("non_performing_rate", "On-time delivery rate", "decreases"),
    ("preventive maintenance", "spindle wear", "mitigates"),
    ("Conditional Correction", "non_performing_rate", "mitigates"),
    ("overtime", "On-time delivery rate", "improves"),
]
G = nx.DiGraph()
for source, target, relation in edges:
    G.add_edge(source, target, relation=relation)

paths = []
for source in ["spindle wear", "sudden stop", "non_performing_rate", "availability"]:
    if nx.has_path(G, source, "On-time delivery rate"):
        path = nx.shortest_path(G, source, "On-time delivery rate")
        paths.append({"Candidate cause": source, "distance": len(path) - 1, "Explanation Route": " → ".join(path)})
display(pd.DataFrame(paths).sort_values("distance"))

pos = nx.spring_layout(G, seed=SEED)
plt.figure(figsize=(9, 6))
nx.draw_networkx(G, pos, node_color="#d9edf7", edge_color="#777777", node_size=1900,
                 font_size=9, arrows=True, arrowsize=16)
edge_labels = nx.get_edge_attributes(G, "relation")
nx.draw_networkx_edge_labels(G, pos, edge_labels=edge_labels, font_size=7)
plt.title("Knowledge graph focusing on on-time delivery rates and causes and countermeasures")
plt.xlabel("Relationships between concepts (placement itself has no quantitative meaning)")
plt.ylabel("Relationships between concepts (placement itself has no quantitative meaning)")
plt.grid(alpha=0.15)
plt.tight_layout()
plt.show()

Reading the results

We were able to list candidates for defect rates and availability, which directly contribute to on-time delivery rates, as well as upstream spindle wear and sudden shutdowns. Preventive maintenance is linked to spindle wear, and conditional compensation is linked to defect rates. The next investigation will check the L3 maintenance records, vibration values, and machining conditions. Simply having a path in the graph does not definitively identify the cause; approval conditions are based on physical inspection and data verification.

No.096: Simulation Platform — Comparing Proposals Based on Result Distribution Rather Than Average

Meaning in Practice

Even if you understand that “maintenance reduces downtime” or “overtime increases production,” demand, stoppages, and yields are not always the same, so you cannot judge the safety of a plan based solely on expected values. The simulation platform records assumptions, random seeds, model versions, and execution results, allowing for reproducible comparison of the proposal.

Approach to Analysis and Modeling

For the week following L3, three options—maintaining the status quo, working overtime, and preventive maintenance—are evaluated 2,000 times each using the Monte Carlo method. The evaluation indicators are demand fulfillment ratio and marginal profit.

$$P(\mathrm{service}\geq 95\%)\approx\frac{1}{N}\sum_{i=1}^{N} I(\mathrm{service}_i\geq0.95)$$

Check with Python

sim_rng = np.random.default_rng(SEED)
scenarios = {
    "maintain the status quo": {"capacity": 104, "stop_mean": 42, "defect": 0.055, "fixed_cost": 0},
    "overtime2hours": {"capacity": 114, "stop_mean": 42, "defect": 0.058, "fixed_cost": 44_800},
    "preventive maintenance": {"capacity": 104, "stop_mean": 18, "defect": 0.030, "fixed_cost": 180_000},
}
sim_rows = []
for scenario, p in scenarios.items():
    for run in range(2_000):
        demand = sim_rng.normal(99, 11, size=7).clip(60)
        stop = sim_rng.normal(p["stop_mean"], 9, size=7).clip(0, 120)
        gross = p["capacity"] * (1 - stop / 480)
        good = sim_rng.binomial(np.floor(gross).astype(int), 1 - p["defect"])
        shipped = np.minimum(good, demand)
        service = shipped.sum() / demand.sum()
        contribution = shipped.sum() * (14_800 - 7_600) - p["fixed_cost"]
        sim_rows.append([scenario, run, service, contribution])
sim = pd.DataFrame(sim_rows, columns=["scenario", "run", "service_rate", "contribution_yen"])
sim_summary = sim.groupby("scenario").agg(
    average_adequacy_rate=("service_rate", "mean"),
    fulfillment_rate_5th_percentile=("service_rate", lambda x: x.quantile(0.05)),
    95percentage_achievement_probability=("service_rate", lambda x: (x >= 0.95).mean()),
    mean_marginal_profit_circle=("contribution_yen", "mean"),
)
display(sim_summary)

fig, ax = plt.subplots(figsize=(8, 4))
for name, group in sim.groupby("scenario"):
    ax.hist(group["service_rate"], bins=28, alpha=0.45, label=name)
ax.axvline(0.95, color="black", linestyle="--", label="Objective95%")
ax.set_title("Demand fulfillment rate simulation for the following week")
ax.set_xlabel("Required adequacy rate")
ax.set_ylabel("Number of trials")
ax.grid(alpha=0.3)
ax.legend()
plt.tight_layout()
plt.show()

Reading the results

The preventive conservation plan reduces the downside risk of fulfillment and increases the probability of achieving the 95% target compared to maintaining the current level. Overtime plans increase capacity but leave worsening defect rates and fluctuations. In decision-making, not only average profit but also 5th percentiles and the probability of achieving goals are arranged, allowing responsible persons to choose how much risk they are willing to accept.

No.097: Optimization Foundation — Balancing Profit and Delivery While Meeting Constraints

Meaning in Practice

While simulation evaluates the results of candidates, optimization searches for good ideas from many combinations. On site, rather than a ‘mathematical optimal solution,’ it is important to have a plan that can be explained and corrected to meet actual constraints such as capacity, demand, minimum supply, contracts, arrangements, and personnel.

Approach to Analysis and Modeling

For the next day’s three products, you will thoroughly explore the production quantity $x_p$ in units of 10. The goal is to maximize marginal profit, with constraints of a total processing time of 720 minutes or less, below product-specific demand, and at least 60 critical product P-C items.

$$\max_x \sum_p m_p x_p\quad \mathrm{s.t.}\quad \sum_p t_p x_p\leq720,\quad 0\leq x_p\leq d_p$$

Check with Python

planning = pd.DataFrame({
    "product_id": ["P-A", "P-B", "P-C"],
    "demand": [100, 90, 80],
    "minutes_per_unit": [2.1, 2.8, 3.6],
    "margin_per_unit": [4300, 5400, 7200],
})

candidates = []
for a in range(0, 101, 10):
    for b in range(0, 91, 10):
        for c in range(60, 81, 10):
            qty = np.array([a, b, c])
            used = float(qty @ planning["minutes_per_unit"].to_numpy())
            if used <= 720:
                margin = int(qty @ planning["margin_per_unit"].to_numpy())
                candidates.append([a, b, c, used, 720 - used, margin])
plans = pd.DataFrame(candidates, columns=["P-A", "P-B", "P-C", "portion used", "extra effort", "marginal_profit_circle"])
best_plans = plans.sort_values(["marginal_profit_circle", "extra effort"], ascending=[False, True]).head(8)
display(best_plans)

fig, ax = plt.subplots(figsize=(8, 4))
ax.scatter(plans["portion used"], plans["marginal_profit_circle"] / 10_000, alpha=0.25, label="Feasible plan")
best = best_plans.iloc[0]
ax.scatter(best["portion used"], best["marginal_profit_circle"] / 10_000, color="red", s=90, label="best plan")
ax.set_title("Feasible production plans and marginal profit")
ax.set_xlabel("Usage time consumed (minutes)")
ax.set_ylabel("Marginal Profit (10,000 yen)")
ax.grid(alpha=0.3)
ax.legend()
plt.tight_layout()
plt.show()

Reading the results

By leaving not only optimal proposals but also higher-level ones, the field can reflect factors outside the model, such as planning and the skills of the person in charge. The practical platform stores input snapshots, constraints, objective functions, solver versions, adoption proposals, and manual revision reasons. If the optimization returns an unexecutable result, it does not silently remove the constraints and presents which constraint mitigations are needed.

No.098: Leveraging AI Agents — Connecting Analysis Results to Secure Proposals and Approvals

Meaning in Practice

AI agents can monitor KPIs, collect potential causes, run simulations, and summarize recommendations. However, because automatically executing equipment shutdowns or ordering can have significant impact, permission boundaries, rationale, approvals, and audit logs are essential.

Approach to Analysis and Modeling

Here, instead of using external LLMs, we create a minimum agent with explicit decision rules. Inputs include KPIs and simulation results, while outputs include proposals, rationale, confidence, and required approvals. Reading, proposing, and executing are separated as authority, and this time we are limiting it to proposals.

Check with Python

l3 = kpi.loc["L3"]
recommended_scenario = sim_summary["95percentage_achievement_probability"].idxmax()
confidence = float(sim_summary.loc[recommended_scenario, "95percentage_achievement_probability"])

agent_log = pd.DataFrame([{
    "agent_run_id": "AGENT-20250331-001",
    "Detection": "L3 KPIHealth level90less than a point",
    "basis": f"OTD={l3['On-time delivery rate']:.1%}, non_performing_rate={l3['non_performing_rate']:.1%}, stop rate={l3['stop rate']:.1%}",
    "proposal": f"{recommended_scenario}Prepare a conservation plan with this candidate as a candidate.",
    "confidence": confidence,
    "automatic execution": False,
    "Required approval": "Manufacturing Section Manager / Security Section Manager",
    "Reference Model": "weekly-simulation:v1.0",
}])
display(agent_log.T.rename(columns={0: "value"}))

guardrails = pd.DataFrame({
    "operation": ["KPIReading", "Cause Candidate Search", "Simulation Execution", "Issuance of Conservation Orders", "equipment shutdown"],
    "Agent Privileges": ["permission", "permission", "permission", "After approval", "prohibit"],
})
display(guardrails)

Reading the results

The agent consolidated L3 anomalies, numerical rationales, reference models, and recommendations into a single auditable record. On the other hand, after approval of a maintenance order, shutting down equipment is outside the authority. In practice, not only prompt countermeasures but also access control, authorized tools, limits on fees and downtime, two-party authorization, and rollback procedures are enforced on the system side.

No.099: Designing Palantir for Manufacturing — Integrating Data, Models, and Business Objects

Meaning in Practice

If the analytics platform, simulation, and workflow are separate, proposals are transcribed to emails or spreadsheets, and execution results do not return to the model. Here, the “manufacturing version of Palantir” refers not to imitating specific products, but to a design philosophy that consistently connects data, semantic layers, models, decision-making, and business actions.

Approach to Analysis and Modeling

Place DecisionCase (decision cases) at the center, associating target lines, KPI anomalies, supporting data, model execution, options, approvals, actions, and effects. Prioritize use cases based on value, feasibility, reusability, and risk.

$$\mathrm{Priority}=0.40V+0.25F+0.20R-0.15K$$

Check with Python

use_cases = pd.DataFrame({
    "use_cases": ["Delivery Recovery", "predictive preservation", "Quality Condition Recommendations", "Inventory replenishment", "Energy Optimization"],
    "value": [5, 5, 4, 4, 3],
    "feasibility": [5, 3, 4, 4, 3],
    "reusability": [5, 4, 4, 3, 3],
    "Risks": [2, 3, 4, 2, 3],
})
use_cases["priority"] = (
    0.40 * use_cases["value"] + 0.25 * use_cases["feasibility"]
    + 0.20 * use_cases["reusability"] - 0.15 * use_cases["Risks"]
)
display(use_cases.sort_values("priority", ascending=False))

fig, ax = plt.subplots(figsize=(8, 5))
scatter = ax.scatter(use_cases["feasibility"], use_cases["value"],
                     s=use_cases["reusability"] * 180,
                     c=use_cases["Risks"], cmap="YlOrRd", alpha=0.75)
for row in use_cases.itertuples(index=False):
    ax.annotate(row.use_cases, (row.feasibility, row.value), xytext=(5, 5), textcoords="offset points")
ax.set_title("DIValue, Feasibility, and Reusability of Use Cases")
ax.set_xlabel("Feasibility (5stage)")
ax.set_ylabel("Value (5stage)")
ax.set_xlim(2.5, 5.5)
ax.set_ylim(2.5, 5.5)
ax.grid(alpha=0.3)
plt.colorbar(scatter, ax=ax, label="Risks (5stage)")
plt.tight_layout()
plt.show()

Reading the results

Recovery on delivery dates offers high value, feasibility, and reusability, making it suitable as the first Decision Case. Parts such as lines, products, KPIs, simulations, and approvals maintained here can be reused for predictive maintenance and inventory replenishment. Rather than collecting company-wide data first, it is realistic to make a single high-frequency decision closed-loop and increase common components.

No.100: The World Surikoubo Aims For — Toward a Factory Where Decision-Making Continuously Learns

Meaning in Practice

The ultimate goal is not for AI to replace the workplace. By combining on-site knowledge with data, statistics, simulation, and optimization, the team enables those in charge to make fast, explainable, and highly volatile decisions. As the execution results return to the next decision, both the model and the business learn from it.

Approach to Analysis and Modeling

Maturity is considered at the stages of visualization, common KPIs, diagnosis, scenario comparison, optimization, and semi-automated execution. Value is measured not only by increasing sales but also by shortening decision-making time, reducing out-of-stock, defects, and stoppages, and minimizing dependence. Here, we present a hypothetical roadmap in which as DI maturity increases, losses from missed deliveries and judgment man-hours decrease.

Check with Python

roadmap = pd.DataFrame({
    "stage": ["Current Status", "commonKPI", "Exploring the Causes", "Scenario Comparison", "Optimized Integration", "Execution with Approval"],
    "DImaturity": [0, 1, 2, 3, 4, 5],
    "monthly_assessment_hours_h": [180, 145, 110, 78, 58, 42],
    "monthly_opportunity_loss_ten_thousand_yen": [920, 780, 610, 460, 350, 280],
    "accumulated_investment_ten_thousand_yen": [0, 180, 420, 760, 1180, 1650],
})
roadmap["monthly_improvement_amount_ten_thousand_yen"] = roadmap.loc[0, "monthly_opportunity_loss_ten_thousand_yen"] - roadmap["monthly_opportunity_loss_ten_thousand_yen"]
roadmap["Simple Collection Months"] = np.where(
    roadmap["monthly_improvement_amount_ten_thousand_yen"] > 0,
    roadmap["accumulated_investment_ten_thousand_yen"] / roadmap["monthly_improvement_amount_ten_thousand_yen"],
    np.nan,
)
display(roadmap)

fig, ax1 = plt.subplots(figsize=(9, 4.5))
ax1.plot(roadmap["stage"], roadmap["monthly_assessment_hours_h"], marker="o", color="#2a6fbb", label="Judgment time")
ax1.set_title("DIMaturity Roadmap and Expected Effects (Hypothetical Estimate)")
ax1.set_xlabel("Implementation Phase")
ax1.set_ylabel("Monthly Assessment Time (hours)", color="#2a6fbb")
ax1.tick_params(axis="x", rotation=20)
ax1.grid(alpha=0.3)
ax2 = ax1.twinx()
ax2.plot(roadmap["stage"], roadmap["monthly_opportunity_loss_ten_thousand_yen"], marker="s", color="#d95f02", label="Missed opportunity")
ax2.set_ylabel("Monthly opportunity loss (10,000 yen)", color="#d95f02")
lines1, labels1 = ax1.get_legend_handles_labels()
lines2, labels2 = ax2.get_legend_handles_labels()
ax1.legend(lines1 + lines2, labels1 + labels2, loc="best")
plt.tight_layout()
plt.show()

Reading the results

With hypothetical estimation, even the common KPIs alone improve decision time and opportunity loss, and the effects accumulate through subsequent diagnosis, simulation, and optimization. The key is not to aim for maturity level 5 from the start, but to measure adoption rates, decision time, KPI improvement, and model deviations at each stage to decide on your next investment. Surikoubo aims for a world where on-site experience is amplified by data, and decisions and results circulate as organizational intelligence.

Practical Implications Seen Through Target Exercise

1. The starting point is decision-making, not data.: Decide first—who chooses, when, what, and which KPIs will evaluate the results.
2. KPIThe definition and granularity of the model preceded the model accuracy: If double counting or definitional differences between departments remain, advanced AI spreads errors more quickly.
3. Semantic layers create reusability: Ontology and knowledge graphs allow cross-departmental reuse of equipment, quality, and delivery schedules.
4. Simulation and optimization have different roles.: Combinations that create candidates through optimization and verify variability tolerance through simulation are effective.
5. AIImplement this including permission design: The proposal can only be put into operations when the rationale, approval, execution limit, audit log, and suspension measures are all present.
6. Measuring effectiveness in a closed loop: Revert recommendations and execution results, update models, constraints, and business rules.

What is necessary for practical implementation

1. Choose one decision item

Rather than broad themes like “factory DX,” select projects with clear responsibilities, frequency, options, and deadlines, such as “decide on a delivery recovery plan every morning within 30 minutes.”

2. Establish data contracts and KPI ledgers

Manage primary keys, granularity, units, missing items, update times, responsible persons, calculation formulas, and target values. If input quality falls below the standard, a mechanism is also needed to stop model execution.

3. Design model operations and business operations simultaneously

It determines not only the accuracy, version, and reproducibility of the model, but also who reviews proposals, how to make corrections in case of exceptions, and who approves them. Record adoption rates, reasons for overwriting, and effectiveness of implementation.

4. Incorporate Security and Safety

We prepare for minimum privileges, separation of duties, operation logs, approval limits, protection of personal information and trade secrets, manual operation during failures, and rollbacks. Direct operation with OT requires a validation environment and phased authorization.

5. Measure effectiveness comparably

Decide time, OTD, defect rate, downtime time, and profit before implementation are saved as baselines and compared to post-implementation. We also consider seasonality and differences in demand structure, and avoid overestimating based on mere before-and-after comparisons.

Conclusion

From No.091 to No.100, manufacturing DI is viewed not merely as visualization or AI implementation, but as a business foundation centered on decision-making. Using hypothetical data, we reviewed KPI design, data models, ontologies, knowledge graphs, simulations, optimization, AI agents, integrated architecture, and a maturity roadmap in a single flow.

If you want to start small, choose one decision that is frequent and high-value, establish common KPIs and data contracts, and record everything from proposal to approval and execution results. This closed loop forms the intelligence foundation for manufacturing, which can be reused for the next use case.

Consultations for Corporations

At Sukari Kobo, you can consult on everything from planning decision-making infrastructure in manufacturing—including KPI and data model design, demand, quality, and equipment analysis, simulation/mathematical optimization, knowledge graphs, and AI agents—to PoC, business implementation, and in-house production support.

Even at stages like “We have data but it doesn’t lead to decisions,” “We want to embed individual PoCs into our operations,” or “We want to continue running simulations and optimizations on-site,” we support you from organizing the decisions you need to make.

📩 Contact Us: surikobo.co.jp/contact
Please feel free to consult us first.