When we started building FINN, one of our earliest architectural decisions looked deceptively simple:
What chart data should we use?
S-57 Electronic Navigational Charts are widely available, proven and supported by an enormous existing ecosystem. We could have built around them, displayed a very good nautical chart, added weather and routing, and moved on.
We decided that wasn’t enough.
Instead, we’re building FINN natively around the S-100 ecosystem and the growing family of S-1xx standards that sit on top of it.
The International Hydrographic Organization has spent years developing S-100 as the next-generation framework for hydrographic and related information. When we began looking closely at that architecture, we realized it solved a much bigger problem for FINN than simply giving us a successor to today’s electronic chart format.
We also knew that choosing to build on an evolving standards ecosystem would mean considerably more work.
We believed the payoff would be far greater.
S-100 gives us more than a technical framework. It gives us the opportunity to build on years of expertise, collaboration and hard-earned knowledge from the hydrographic and broader maritime communities that came before us. Instead of starting with a blank sheet of paper and deciding for ourselves how marine information should be structured, related and exchanged, we can learn from that work, implement it and extend from a much stronger foundation.
And as FINN grows, we don’t want that relationship to flow in only one direction.
We want to participate in that community, learn from it and, where our work and experience can be useful, contribute back to it.
That has value far beyond standards compliance.
It accelerates our ability to solve the problems FINN was created to solve while giving us an architecture capable of growing as both the standards and our intelligence engine evolve.
For us, the additional engineering effort wasn’t simply a cost.
It was an investment in starting from decades of accumulated maritime knowledge instead of starting over.
And that brings us back to what we’re actually trying to build.
A chart is not the product
FINN isn’t intended to be another electronic chart with some smart features attached to it.
We’re building a marine intelligence engine.
That distinction matters.
A traditional navigation application primarily needs to answer questions like: Where am I? Where is the channel? Where are the hazards? How deep is the water? How do I get from here to there?
FINN eventually needs to reason about a different class of questions: What do the surrounding conditions mean for this particular boat? How will the expected water level, current and weather interact with the planned passage? What hazards become relevant given the vessel’s draft, course, speed and expected position? Has something changed since the voyage was planned? What has FINN learned about how this boat actually performs? What does FINN know about the captain and crew that changes what information matters? What deserves the captain’s attention now — and what doesn’t?
Those questions require more than pixels on a map.
They require structured, attributable and interoperable information.
But that doesn’t make the chart less important. It makes it more important.
The chart is still foundational
Saying that FINN isn’t being built as a chartplotter-first product doesn’t mean charting is secondary. Quite the opposite.
First-class charting is foundational to the intelligence engine we’re building.
A nautical chart is an important source of information in its own right. It describes the navigational environment around the vessel: depths, hazards, aids to navigation, channels, restricted areas, shoreline features and much more.
But for FINN, the chart also plays another critical role. It gives intelligence context.
Knowing that the weather is changing is useful. Knowing that the weather is expected to change as the boat approaches an exposed section of its planned passage is much more useful.
Knowing the current is running at a particular rate and direction is data. Understanding how that current relates to the vessel’s expected position, nearby navigational features and planned course at a particular time begins to turn that data into an insight.
The same is true for water levels, navigational warnings, hazards and eventually information FINN learns about the boat and the people aboard it. All of those inputs need accurate spatial and temporal reference points. The chart helps provide them.
FINN needs to understand the navigational environment well enough to answer where the boat is now, where it is expected to be next, what surrounds it, what will surround it later in the passage, and which pieces of everything FINN knows become relevant because of that location and time.
This is why we don’t see charting and intelligence as competing priorities.
FINN doesn’t need to become a traditional chartplotter simply because charts are important. But if we’re going to generate trustworthy, timely insights about a voyage, our underlying representation of the navigational environment needs to be excellent.
The chart isn’t the intelligence engine. But it’s one of the foundations that lets the intelligence engine understand where and when everything else matters.
Once we reached that conclusion, our original question became much more important: What kind of hydrographic data foundation should we build on?
Why standards matter to FINN
There’s a broader principle behind this decision.
Standards matter to us.
Not because implementing a standard automatically makes a product better, and not because we believe every good idea needs to originate from a standards body.
Standards matter because FINN is being built to bring together information produced by many different organizations, devices and systems — and then understand how those pieces of information relate to one another.
That only works at scale when information has dependable meaning.
A depth needs to retain its meaning when it crosses a system boundary. A navigational feature needs a defined identity and set of attributes. Units, relationships, metadata, provenance and updates need rules that don’t change simply because information moved from one system to another.
Good standards create those shared contracts. They also create boundaries.
That’s important to us because we don’t want FINN’s architecture to depend on one company, one data provider, one sensor manufacturer or one generation of marine electronics.
Where strong, open maritime standards exist, our preference is to build on them rather than unnecessarily create proprietary alternatives. Where standards don’t yet cover something FINN needs, we can develop our own models behind clearly defined boundaries while preserving the ability to map them to future standards.
That gives us something extremely valuable:
Freedom to innovate above the standard without unnecessarily reinventing what the industry has already solved below it.
It also reflects the relationship we want FINN to have with the broader maritime standards community.
We want to consume its expertise, certainly. But over time, we also want the lessons we learn building and operating FINN to become part of the conversation.
Standards are strongest when they capture real knowledge from across a community. We want FINN to be a participant in that process, not simply a consumer standing outside it.
The IHO isn’t designing FINN’s intelligence engine. That’s our job.
But the increasingly structured and interoperable marine information environment being created through S-100 gives us a much stronger foundation on which to build one.
Why S-57 wasn’t enough — but isn’t going away
S-57 has served electronic navigation extraordinarily well. It provides the foundation for the Electronic Navigational Charts used throughout today’s navigation ecosystem. It was designed for that job, and it remains extremely important.
Our decision to build toward S-100 is not a decision to abandon S-57.
In fact, the transition designed by the IHO recognizes this reality through what it calls Dual Fuel: a period in which S-57 and S-101 data coexist while hydrographic offices, distributors, equipment manufacturers and mariners transition toward S-100.
FINN is being engineered to operate in that world.
Because real boats don’t sail through standards roadmaps. They sail through whatever authoritative information is actually available for their location today.
If the best available chart coverage is S-57, FINN needs to use it well. As S-101 coverage becomes available, FINN needs to take advantage of the richer S-100 environment.
So S-57 remains an important input.
What we didn’t want was for the boundaries of S-57 to become the boundaries of FINN.
Giving S-57 a bigger world to live in
There’s an interesting consequence to this architecture.
FINN operates natively in an S-100-oriented information environment. That means we don’t have to treat S-57 simply as a legacy chart format running down a completely separate path.
We can ingest authoritative S-57 information, preserve its provenance and limitations, and translate it across a deliberate boundary into FINN’s broader model of the marine environment.
That doesn’t manufacture information that wasn’t present in the original S-57 dataset. But it gives that information new context.
An S-57-derived navigational feature can participate in reasoning alongside newer sources describing water levels, currents, weather, warnings, vessel state and other information that never existed together within the S-57 model.
In that sense, supporting S-57 inside an S-100-native architecture doesn’t just preserve compatibility with today’s chart ecosystem.
It allows today’s data to participate in tomorrow’s information environment.
Dual Fuel and our dual-track strategy aren’t the same thing
There’s an important terminology distinction here.
Dual Fuel is the IHO transition strategy supporting the coexistence of S-57 and S-101. FINN supports that approach.
Separately, we use what we call a dual-track engineering strategy for implementing evolving standards.
On one track, FINN maintains a production implementation grounded against released specifications. That gives us a known, reproducible baseline against which behavior can be implemented and tested.
On the other, we continuously evaluate newer revisions and credible forward-standard material.
Why? Because we’d rather discover tomorrow’s architectural problem today.
If an evolving specification introduces a new concept or changes an existing one, we want to know whether FINN’s architecture can accommodate it before years of product development depend on the old assumption.
Where forward-looking behavior is useful but isn’t yet appropriate to treat as established production behavior, we can isolate it, preserve its exact provenance and clearly identify its status.
Dual Fuel helps us live in the transition from S-57 to S-101.
Dual track helps our engineering live with the continued evolution of S-100 itself.
They solve different problems, and both matter.
S-101 is only the beginning
If S-100 were simply a better way to encode an electronic chart, this probably wouldn’t justify all this effort.
But S-101 is only one part of the S-100 ecosystem.
Alongside next-generation Electronic Navigational Charts are specialized products such as S-102 — Bathymetric Surface, S-104 — Water Level Information, S-111 — Surface Currents, and S-124 — Navigational Warnings, along with a growing family of specifications describing other parts of the marine environment.
For FINN, that’s enormously important.
The intelligence engine shouldn’t have to extract all of its understanding from a picture of the world.
We want the underlying meaning.
From chart objects to an understanding of the environment
S-100 product specifications can provide machine-readable descriptions of features, attributes, relationships, portrayal and encoding.
That might sound like an obscure standards detail. For an intelligence engine, it isn’t.
It means software can increasingly understand not simply that something should be drawn at a particular location, but what that thing represents, which properties belong to it and how it relates to other information.
That gives us a much stronger foundation for constructing FINN’s model of the marine environment.
The ENC can describe navigational features. Bathymetric information can describe the underwater surface. Water-level information can describe changing depth conditions. Current information can describe movement of the water. Weather systems can contribute atmospheric conditions and forecasts. Navigational warnings can describe temporary or emerging hazards.
And interoperability isn’t incidental to the S-100 ecosystem. It is important enough to have its own specification: S-98 addresses how S-100 data products operate together in navigational systems.
That’s especially interesting to us because the environment is only half of the problem.
FINN also needs to understand who and what is moving through it.
The boat isn’t the only thing we’re learning
Understanding the environment is only useful if FINN can also understand the vessel moving through it.
A generic polar or manufacturer’s specification can tell us something about how a boat should perform. What FINN observes over time can tell us how this boat actually performs.
That difference is fundamental to the intelligence engine we’re building.
But the vessel is only the beginning.
Ultimately, we want FINN to progressively understand the boat, the captain, the crew and, where relevant, the passengers.
Because the same conditions don’t mean the same thing to everyone.
A depth that is completely unremarkable for one vessel may matter enormously to another.
A weather change that an experienced crew on a well-equipped vessel barely notices may deserve considerably more attention on a small recreational boat with a family aboard.
A long passage, deteriorating conditions or changing sea state may have implications that can’t be understood from the chart alone.
S-100 doesn’t provide those human and vessel models for FINN.
We do.
What S-100 gives us is an information architecture designed around multiple well-defined models and interoperable information rather than a single monolithic chart dataset.
That philosophy maps remarkably well to what an intelligence engine needs.
Hydrographic information can remain hydrographic information. Weather can remain weather. The vessel can have its own model. The captain, crew and passengers can have theirs. The voyage and its history can have theirs.
FINN can reason across those boundaries without requiring any one model to become everything.
No single data source gets to own FINN
That leads to another architectural decision we’ve made.
FINN shouldn’t be tightly coupled to a particular data provider — or assume that every useful future source will arrive through an existing IHO product specification.
We’ve deliberately created agnostic boundaries between external information and FINN’s internal model.
An S-101 dataset can be one source of navigational information. An S-57 ENC can be another. Weather may arrive from completely different providers. Sensor observations may come from the device running FINN. An instrumented vessel may contribute its own telemetry. Future sources may provide information we haven’t even considered yet.
Those sources can differ in transport, encoding, update cadence and underlying data model without requiring the intelligence engine itself to understand every provider’s peculiarities.
The boundary translates the outside world into concepts FINN understands while preserving something equally important: where the information came from.
That provenance matters when you’re building a system that will eventually reason across many sources with different capabilities, limitations and levels of authority.
The long-term question therefore isn’t simply: “Can FINN read S-101?”
It’s: “Can FINN understand trustworthy marine information regardless of how it arrived?”
Built to grow
The S-100 ecosystem isn’t limited to a fixed collection of datasets designed once and frozen forever. Its broader framework anticipates the development of new maritime information products.
That aligns with how we’re designing FINN.
Where an established standard meets the requirement, we want to support it. Where multiple providers supply equivalent information, we want the architecture to accommodate them. And where a new kind of marine information becomes useful, we don’t want our entire intelligence architecture constrained by the formats that happened to exist when we wrote version 1.0.
The standards can evolve. The providers can change. New sources can emerge.
The intelligence engine shouldn’t have to be rebuilt every time they do.
Intelligence shouldn’t require an expensive instrument panel
There’s also a much more human reason we chose this architecture.
One of our core principles at FINN is simple:
Bring the best marine technology we can build to the largest population of boaters we can reach.
We don’t believe an intelligence engine should require a new boat, an expensive electronics refit or thousands of dollars of networked instrumentation before it becomes useful.
A surprising amount of useful information may already exist in someone’s pocket.
Modern phones can provide location, course, speed, motion and other sensor-derived information. External sources can provide hydrographic and environmental information.
For a small boat with little or no instrumentation, that can provide the beginning of a meaningful model.
At the other end of the spectrum, a sophisticated vessel may provide a rich stream of onboard telemetry through NMEA-connected instruments and systems.
FINN needs to live across that entire range.
A sailor stepping aboard a small boat with little more than an iPhone should be able to benefit from the same underlying intelligence architecture as someone aboard a highly instrumented vessel.
The amount and precision of information available to FINN will obviously differ.
The architecture shouldn’t.
Additional trustworthy sources should enrich the model rather than determine whether the model can exist at all.
That leads to another principle we’ve adopted:
Better instrumentation should make FINN better. It shouldn’t be the price of admission.
S-100 fits that philosophy extraordinarily well because it helps us think in terms of interoperable information rather than a single privileged source.
One environment, many models
Put all of this together and the architectural requirement becomes clearer.
FINN ultimately needs to bring together models of the navigational environment; weather, water levels and currents; temporary conditions and warnings; the vessel; onboard and device sensors; the planned and actual voyage; the captain; the crew and passengers; and the history from which FINN learns.
No single one of those models is the intelligence engine.
The relationships between them are where intelligence begins.
Consider something as simple as a depth.
By itself, it’s data.
Add expected water level and we know more.
Add the vessel’s draft and it becomes personally relevant.
Add the planned route and expected arrival time and it becomes predictive.
Add current and weather and the situation becomes more dynamic.
Add a navigational warning and the risk picture may change again.
Add what FINN has learned about the vessel, captain and crew and we can begin determining not merely what is happening, but whether it matters enough to say something about it.
That’s a fundamentally different problem from displaying a chart.
And it’s the problem we want FINN to solve.
Why take on all this complexity?
There is certainly an easier path.
We could consume existing chart data, render it, bolt on weather APIs, add routing and build intelligence around whatever normalized information happened to emerge.
That would get us to market faster.
It would also create exactly the architecture we’re trying to avoid.
Intelligence systems are only as good as the information architecture underneath them.
If every source enters the system through a different set of assumptions, naming conventions and lossy transformations, increasingly sophisticated reasoning gets built on increasingly fragile foundations.
We would rather pay that architectural cost now.
FINN’s long-term advantage isn’t simply going to come from having access to marine data. Many companies can obtain the same data.
The opportunity is in understanding how those pieces of information relate to one another, to the voyage, to the people aboard and to the individual vessel.
S-100 isn’t the intelligence engine
This distinction is important.
S-100 doesn’t magically make navigation intelligent.
It gives us something much more useful:
a structured, extensible foundation upon which intelligence can be built.
FINN still has to ingest information from different sources, validate it, preserve provenance, normalize it into its internal models, reconcile versions and providers, understand the vessel and the people aboard, learn from history, and determine what actually deserves the captain’s attention.
That’s our work.
And it’s why we’ve spent far more time implementing hydrographic standards than we originally expected.
We’re not implementing standards for the sake of implementing standards.
We’re building the information foundation that we believe a real marine intelligence engine requires.
S-57 remains an important part of that foundation today.
S-100 gives us a path far beyond it.
And by keeping the intelligence engine independent of any one format, provider or level of onboard instrumentation, we’re trying to ensure FINN can continue understanding the marine environment as the information available to mariners evolves.
Because ultimately, the goal isn’t to display more data.
It’s to understand what that data means for your boat, the people aboard it and the voyage ahead — and to know what matters next.