CAYNMARS NEO OS™
A decision and evidence layer that binds AI data centre load and on-site distributed energy to one commercial basis. Designed and built in-house by CAYNMARS.
Design it. Prove it. Permit it. Carry it into the returns.
CAYNMARS does not wait in a grid connection queue. We build a structure that generates power on site and supplies the AI data centre directly. At that moment everything the grid used to handle — at what cost power is produced and at what quality it is delivered — becomes the developer's own responsibility, and CAYNMARS NEO OS is the software built to carry it.
Power for an AI data centre has shifted from a question of how much is needed to a question of how fast it moves. Rack density has risen from single-digit kW into the tens of kW, and tens of thousands of accelerators ramp power up and down together at synchronisation points.
On that load we size the power architecture, produce the tests needed to prove it, check grid impact and permitting requirements during design, and feed availability, settlement and emissions back into the financial model. Four jobs normally done by four teams in four separate documents.
An OS that designs the power system for an AI data centre, proves the design is right, carries it through permitting, and connects the result to returns and financials.
The three are the core identity; the rest are extensions built on top. Design → verify → permit → finance is the order in which that intersection works.
What is different about power for an AI data centre
| Aspect | Conventional data centre | AI data centre |
|---|---|---|
| Rack power density | Single-digit kW per rack | Tens of kW per rack — the cooling approach itself changes |
| Load over time | Gentle daily and weekly cycles | Tens of thousands of accelerators ramp together at synchronisation and checkpoint moments |
| Scale where it shows | Hourly averages suffice | Intervals that look normal on a one-minute average can be hazardous at sub-second scale |
| Kinds of load | One profile approximates it | Training, fine-tuning and inference each have a distinct electrical signature |
| Conventional models | Constant-power and ZIP load models apply | Those models cannot represent the behaviour — the time scale and dynamics sit outside their assumptions |
← Swipe the diagram sideways to see all four stages.
Capability × stage — what happens at each step
| Capability ↓ / Stage → | 01 DesignDESIGN | 02 VerifyVERIFY | 03 PermitPERMIT | 04 ReturnsFINANCE |
|---|---|---|---|---|
| AI-load nativeAI-LOAD NATIVE | Training, fine-tuning and inference defined as distinct electrical load profiles, then generation, storage and grid intake sized against them | Generates voltage-dip, transfer and load-step scenarios per load mode and judges the response required | Produces the load characteristic data a grid impact assessment requires, straight from the design output | Quantifies how each operating mode affects availability and settlement |
| Verification nativeVERIFICATION NATIVE | Structures the design output so it is already in verification input form | Produces “what must be tested to prove this configuration” as items, sequence and timing HILFATSAT | Verification results carry through as the evidence base for permitting documents | Verified availability becomes an input to debt service coverage DSCR |
| Regulatory nativeREGULATORY NATIVE | Contracted demand and intake limits built in as design constraints — not a review after the fact | Maps the test items that applicable rules require into the verification plan | Checks grid impact assessment and electricity business law requirements during design | Reflects how tariffs, levies and regulatory change affect cash flow |
← Swipe the table sideways.
Permitting is one of four stages, and all three capabilities pass through it. Each entry describes a functional element of the software; quantitative performance is provided under mutual NDA.
Capability maturity — where we are and where we are going
| Capability | Now 2026 |
Stage 1 ~2027 | Stage 2 ~2030 | Note |
|---|---|---|---|---|
| Design & economics Configuration optimisation, returns |
◎ | ◎ | ◎ | Already in place — not a differentiator |
| Verification pipeline Design → HIL → FAT/SAT → measurement |
○ | ◎ | ◎ | The axis that completes soonest |
| Regional regulatory engine Korea → Asia |
○ | ◎ | ◎ | Domestic rules in progress |
| Low-carbon fuel pathway Fuel transition scenarios |
○ | ○ | ◎ | Fuel cell and hydrogen models in hand |
| AI-load native modelling Per mode, sub-second dynamics |
△ | ○ | ◎ | Core differentiator — to be calibrated on measurement |
| Grid flexibility valuation Demand response, balancing |
△ | △ | ○ | Market participation is a partner domain |
| Real-time equipment control Control and protection |
interface | interface | interface | Not something we build |
◎Core ○In place △In development interfaceNot built in-house; connected over standard protocols · our own assessment
What we do not do
CAYNMARS does not build the layer that controls equipment directly. Control and protection systems already installed stay in place; we connect over standard protocols and sit above them. Trading resources in the power market is likewise a specialist's domain, and we partner there. Drawing the boundary clearly is how we take responsibility for the result.
Permitting is where a project starts, not where it ends
After consent is granted, what decides the project is whether the contracted power was actually delivered, what that settles to under the contract, and what emissions record it leaves.
All three are values produced directly from operating data. NEO OS was built to take them straight into the financial model — so the metrics a lender or investor examines in diligence sit next to the assumptions the design was built on.
The financial analysis function returns a simulation based on the assumptions entered. It does not guarantee or forecast future returns.
All four stages are developed in-house and in preparation for demonstration. The permitting review function checks statutory and grid requirements during design; it does not guarantee any permitting outcome. See how the regulatory environment is changing →
Six things, one basis
Controlling the power, holding its quality, proving what was delivered and settling it in money — six jobs that normally sit in separate systems, placed on one basis.
Measure → dispatch → verify → settle, and the result feeds the next decision.
Control & dispatch
Generation, storage and load read as one power structure — deciding what runs now, and what stays in reserve.
Quality & monitoring
Voltage, frequency and other power-quality measures watched continuously, with drift caught before it becomes a fault.
Distributed resources (VPP)
Scattered generation and storage aggregated so they can move as a single block when needed.
Availability & settlement
Measuring what was actually delivered against what was promised, and settling it against contract.
Financial model analysis
Operating results fed back into the business model, so the project's real economics stay visible.
Carbon footprint tracking
Emissions accounted for and recorded in a form customers can drop straight into their own reporting.
It sits above the systems already installed
Field equipment and existing commercial systems stay as they are; only what is needed for commercial judgement is unified above them. Adoption carries no replacement risk.
Credibility established through third-party verification
We do not rest on our own test results. We set out the scope and schedule of verification ourselves, then fill each stage with independent external verification.
"In discussion" does not mean an institution has performed or endorsed a verification. It means scope and schedule are being discussed. On execution or completion we change the status and publish the supporting document. Institution names are disclosed once agreements are confirmed.
Verification follows an order
Verification of a power project does not happen in one pass. What can be done at design stage, what needs the equipment vendor fixed, and what can only be done after commissioning are separated by the standards themselves. Rather than hide what is not yet there, we set out when each part gets filled in, and with what.
Power quality is not something a design-stage simulation can adjudicate. The standard itself requires judgement against data measured on site, over a defined period, after commissioning. A conventional grid-supplied data centre follows the same sequence. So we do not warrant this item today; we manage it through design basis and a measurement plan.
What we publish, and what we keep
The core structure of the software has been filed for patent, opening the route to a granted right. The parameters and formulas that actually produce the answers were kept back as trade secrets. We say where each sits. We do not publish the contents.
Published layer — algorithmic structure
In August 2026 we filed a patent application covering the core structure of the power operations software for AI data centres (under examination; four inventions included). It becomes a right only if granted.
We disclose the technical field, the title of the invention and the stage it is at. Application number and claims are provided after a mutual NDA.
Withheld layer — parameters and formulas
Failure-rate and repair-time coefficients, financial formulas and load profiles were left out of the filing. They are registered under five trade-secret original registrations (Korea Institute of Intellectual Property Protection, August 2026), fixing possession and date in law.
Original registration evidences that we held this material at that point in time. It is not a quality mark and not a government certification.
Note: the patent, trademark and copyright items above are applications pending examination. Registration depends on the outcome of that examination. Filing is neither a granted right nor an endorsement of technical performance.
Operating screens are not published
Operating screens carry plant and commercial information together. Substituting a staged screen would breach our own principle of not overstating. We offer a live demonstration under an NDA instead.