Finite Field
30-sec diagnosis

Mathematical systems engineering

For plans people rebuild every day, let the system plan

Shifts, visit schedules, dispatching, production steps, and staff assignments. We turn complex decisions that depend on Excel and experienced operators into mathematical models, then implement them as usable web and app systems for the field.

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

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

Problems we solve

When the work is full of constraints, ordinary system development misses the core.

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

01

Manual plans keep breaking

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

02

Rules are hard to see

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

03

Experts absorb the complexity

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

04

The system does not decide

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

The answer is not just a nicer screen. It is 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 operation UI 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 with a screen list. We first break field 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 from a screen list. We first define decision variables, constraints, objectives, and explanation requirements, then turn them into a product people can operate.

Interactive assignment demo

Try how a rule-heavy schedule changes when it becomes a mathematical model.

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

Visit scheduling planner

Change the objective and run the planner.

Manual plan: two constraints need correction

Sample: 9 visits / 5 workers

Solution areas

We build around the decision, not around a generic screen category.

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.

01

Inventory rules and data

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

02

Build the model

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

03

Prototype the operation

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

04

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 logic is worth 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
Touchable 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. The home page introduces the direction and sends deeper technical readers to NPA and related work.

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

Answers are written for teams that are considering whether operational decisions should become 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: data check, rule organization, and a touchable prototype. Full production development starts after the model and operation fit are clear.

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

Start with a small model and a touchable prototype. We will separate what should be automated from what should stay as human judgment.

Contact us

30-second check

Can this workflow become a mathematical system?

Which workflow causes the most decision rework?