Mathematical systems engineering

Let the system handleplans people rebuild every day.

Shifts, visit schedules, dispatching, production steps, and staff assignments all involve complex decisions. We model the rules now held in spreadsheets and experienced operators' heads, then build practical web and mobile systems for the people doing the work.

Try the assignment demo

Prototype in as little as two weeks Web, iOS, and Android Built around site-specific rules

Constraint solver

Optimized · 0.38s

Visit schedule / June 20

Prototype in as little as two weeks

Optimized

Aoki

Ito

Sato

Hayashi

09:00

V-012North / Care

V-008East / Rehab

11:00

V-003Central / Mental

V-021West / Child care

13:00

V-017North / Rehab

V-026South / Mental

Constraint issues

Total travel

84 min

Assignment rate

100%

min Σ cᵢxᵢ + λΣ vⱼ
s.t. Ax ≤ b

Problems we solve

Scheduling Field work Routing Matching

Featured solution MPK Assurance

For critical Go code,do not stop at tests.

For critical Go logic that moves money, such as refunds, fees, balances, and reserves, we mechanically check whether specified properties hold under explicit assumptions and scope. Gemini generates proof candidates, and the independent MPK kernel makes the final verdict.

Refunds Fees Balances Reserves Discounts Allocations

Assurance beyond tests

Check the specified property across the target scope, not only selected inputs.

Start with one Go function

Start from a critical policy function, not a special proof language.

Do not trust AI directly

AI prepares candidates; final acceptance belongs to the independent kernel.

View MPK Assurance Watch the 30-second refund demo

refund.go

func ApplyRefund(paid, refunded, amount int64) (int64, error) {
  if amount < 0 || refunded+amount > paid {
    return 0, errors.New("invalid refund")
  }
  return refunded + amount, nil
}

Property to verify Cumulative refunds ≤ amount paid

COUNTEREXAMPLE FOUND Shows concrete inputs that violate the property.

KERNEL VERIFIED The independent kernel accepts the certificate for the fixed version.

Go function→Gemini prepares candidates→MPK checks independently

Limited to the first 5 companies

MPK Early Adoption Offer

~~Standard JPY 198,000~~ JPY 49,800 before tax

For companies willing to share candid feedback after service completion and cooperate on a pre-approved case study.

View the offer

Check the conditions and publication details on the dedicated page.

Problems we solve

When work is full of constraints, conventional software development can miss the real problem.

Finite Field works on operations that are too rule-heavy for a simple form system and too specific for a generic SaaS product.

Manual plans keep breaking

A person rearranges work every time a shift, visit, delivery, or order changes.

Rules are hard to see

Skill, capacity, location, due date, and priority rules exist, but they are scattered across spreadsheets and people's memory.

Experienced staff handle every complex adjustment

The same data is copied between Excel, chat, and systems, then corrected by the same expert.

The system does not decide

A system exists, but it only records results. The hard part still happens outside the system.

A better interface is not enough. The system also needs a model that can decide and explain.

We treat these as mathematical systems: model the decision, test the constraints, explain the result, and build the operational interface around that logic.

From business rules to a system model

When decisions are repeated, the system needs a mathematical layer.

Finite Field does not begin by listing screens. We first break operational decisions into variables, constraints, objectives, and explanation requirements, then design the system.

Variables

Workers, visits, machines, orders, vehicles, time slots, skills, capacity, and dates become explicit data.

Constraints

Skills, deadlines, locations, load limits, priorities, unavailable times, and business exceptions are written as rules.

Objectives

Reduce travel, balance work, improve preference fit, protect due dates, or make trade-offs visible for operators.

We do not start with a list of screens. We define the decision variables, constraints, objectives, and explanation requirements first, then turn the model into a product people can use.

Interactive assignment demo

See how a mathematical model improves a schedule with many competing rules.

The browser demo is explanatory. It does not send your data outside this page.

Visit scheduling planner

Change the objective and run the planner.

Optimization objective

Manual plan: two constraints need correction

Sample: 9 visits / 5 workers

Solution areas

We design around the operational decision itself, not a generic type of interface.

We focus on planning work that is rebuilt every day: shifts, visits, dispatching, production steps, and staff assignments.

Scheduling

Shift and staffing optimization

Turn skills, time slots, rest rules, and fairness into a schedule that can be reviewed.

Field work

Visit and route scheduling

Assign visits and field work while considering travel, skill fit, preferred staff, and time windows.

Routing

Vehicle routing and delivery planning

Plan vehicles, deliveries, and stops under capacity, sequence, and service constraints.

Matching

Assignment and matching systems

Match people, cases, orders, or resources with explainable priorities and exceptions.

Delivery process

Model first, prototype next, production only after the fit is clear.

We keep the first step narrow enough to validate the model before committing to a production system.

Inventory rules and data

Collect current spreadsheets, rules, examples, and exceptions, then identify where decisions actually happen.

Build the model

Turn the workflow into variables, constraints, objectives, and explanation requirements that can be reviewed.

Prototype the operation

Create a small interface around the model so operators can work through the workflow and find missing rules.

Plan production development

Decide the production scope only after the data, model, usability, and risk assumptions are visible.

First step

Start small, then decide whether to build the full system.

For uncertain workflows, we start with a narrow prototype: model the rules, build a small UI, and verify whether the workflow is ready for production development.

Prototype from ¥298,000

The prototype clarifies feasibility and scope. It does not guarantee business effects.

Rule and data inventory

Small optimization or matching model

Interactive workflow prototype

Next-scope proposal with risks and assumptions

Research to product

Model, verify, operate

NPA

Verification

Products

Math Lab

We keep research close to implementation.

The lab connects mathematical modeling, proof-oriented thinking, and software delivery. This page gives an overview; NPA and related work provide the technical details.

Research content supports engineering judgment; it is not positioned as a replacement for production validation or formal proof tools.

Read about NPA

FAQ

Common questions before a first consultation

For teams deciding whether to turn operational decisions into software.

What kind of work can become a mathematical system?

Scheduling, assignment, routing, matching, production planning, and other workflows with many constraints are good fits. We first turn the business rules into a small model before deciding what to build.

Do you guarantee business results?

No. The prototype and demo clarify feasible logic, data requirements, and user experience. They do not guarantee cost reduction, sales growth, or other business effects.

Can we start before all requirements are fixed?

Yes. We usually keep the first step small: check the data, organize the rules, and build an interactive prototype. Full production development starts only after the model fits the operation.

Bring rule-heavy decisions into a system that can be explained, tested, and operated.

Start with a small model and an interactive prototype. Together, we will separate the decisions worth automating from those that should remain with people.