01
Manual plans keep breaking
A person rearranges work every time a shift, visit, delivery, or order changes.
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.
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
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
0
Total travel
84 min
Assignment rate
100%
min Σ cᵢxᵢ + λΣ vⱼ
s.t. Ax ≤ b
Problems we solve
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.
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 NPAFAQ
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.