Author: ken.rowe

Most people will first encounter FINN as an app, which makes one of our earliest technology decisions sound fairly ordinary: we chose Swift to build our first mobile version of FINN.

iPhone app. Apple language. Obvious choice.

Except that wasn’t really the decision we were making.

FINN is a marine intelligence engine. We’re building it to bring together information about the boat, the voyage, the surrounding environment and the people aboard, then help captains and crews understand what matters in their particular situation.

A chart can tell us where the boat is, weather data can tell us what’s approaching, and sensors can tell us how the boat is moving. Over time, observations can begin to tell us something more specific: how this particular boat actually behaves.

But none of those sources is the intelligence engine by itself. What interests us is what becomes possible when FINN can understand the relationships among them.

That creates a technology problem very different from simply building an app. FINN may begin on a phone, but we expect its intelligence to eventually operate across phones, tablets, computers, cloud infrastructure and computing aboard the vessel itself. More importantly, several of those systems—and several people aboard—may be participating in FINN at the same time.

So the question we actually needed to answer was broader:

How do we build FINN once without requiring every place FINN appears to be the same?

That question led us to Swift, but not before trying—and seriously considering—some very good alternatives.

What our first prototype taught us

FINN didn’t begin with Swift.

Our first working proof of concept was an onboard appliance built around a Raspberry Pi and dedicated display. A deterministic backend processed vessel state, calculations, rules and insights, while a React and TypeScript interface gave us a way to interact with the system. We didn’t just prototype that architecture on a development computer; we ran it on the actual hardware.

It taught us a lot.

React worked well as an interface to FINN. What we became less convinced of was that the application framework should become the architecture of FINN.

That distinction became increasingly important when we decided the phone should become FINN’s first broadly accessible platform. We could have continued down the React path with React Native, sharing substantial portions of an application between iOS and Android. We could have chosen Flutter, another mature approach to building applications for multiple platforms from a shared codebase. At the opposite extreme, we could build entirely separate native applications—Swift for Apple, Kotlin for Android—and accept the duplication.

None of those approaches is inherently wrong. They optimize for different things.

React Native and Flutter solve a real and expensive problem: developing software for multiple platforms without building everything multiple times. Modern React Native can also move shared platform-independent functionality into C++ native modules, while Flutter compiles release applications to machine code and provides mechanisms for interacting with native platform code.

Those are meaningful advantages, and we considered them. But our experience with the original appliance led us to frame the problem differently.

Instead of asking how much of the application we could reuse, we began asking:

What part of FINN do we actually want to make portable?

Our answer wasn’t the interface.

It was the intelligence underneath it.

What should actually be portable?

Underneath FINN’s interface we’re building models of the vessel, voyage and marine environment. We’re processing hydrographic information and sensor observations, developing deterministic calculations and spatial capabilities, estimating vessel state, preserving history and laying the foundations of an intelligence system that can understand relationships among all of them.

Eventually, the screen displaying an insight may be one of the least interesting parts of the process that produced it.

Those underlying capabilities need to survive whatever happens to the interface above them. That’s why we’ve adopted a somewhat different definition of cross-platform development:

The experience can belong to the platform. The intelligence belongs to FINN.

Internally, we’ve described the same principle as one FINN, multiple embodiments.

That doesn’t mean every environment needs to run identical software, or even that every FINN component needs to be written in the same language. It means the important concepts shouldn’t change depending on where FINN happens to be running.

A vessel observation should mean the same thing. A voyage should mean the same thing. What FINN has learned about a boat shouldn’t quietly diverge because one system is running aboard the vessel while another is in a crew member’s pocket or somewhere in the cloud.

That consistency becomes even more important when those systems begin working together.

One FINN can span a vessel

Our first broadly available version of FINN starts on the phone, but we don’t think of the phone as FINN’s eventual home. It’s simply a particularly useful place to begin.

The larger opportunity isn’t just moving FINN from one kind of device to another. It’s allowing several devices, potentially running very different systems and serving different people, to participate in the same FINN experience.

Imagine planning a passage on a computer at home, where a large screen, keyboard and mouse make detailed planning comfortable. That plan follows the captain and crew aboard. Phones can provide mobility and sensing, while a tablet provides more room for charts, environmental context and information at the helm. A dedicated onboard computer can eventually process vessel and sensor data continuously, while cloud services synchronize the information that should follow the vessel and its people between them.

And this doesn’t have to be a one-person, one-device relationship.

A vessel may eventually have multiple active instances of FINN serving different roles at the same time. The captain might use a tablet at the helm while a crew member carries a phone elsewhere aboard. Another crew member might need information relevant to a different responsibility, while an onboard system continues processing vessel and environmental data in the background.

Those instances don’t need identical interfaces, capabilities or permissions. What matters is that they’re participating in the same understanding of the vessel and voyage.

A course change shouldn’t become a different voyage because it was entered from another device. An observation made by one instance of FINN should retain its meaning when it becomes relevant to another. What FINN has learned about the vessel should belong to the vessel’s evolving context, not be trapped inside whichever screen happened to collect it.

Over time, that creates room for role-aware experiences. A captain, navigator or crew member may need different information at different moments. The goal isn’t to put every piece of information on every screen, but to make the appropriate information available to the appropriate person while keeping those experiences grounded in the same underlying FINN.

That’s what one FINN, multiple embodiments means to us.

We don’t necessarily need the same application everywhere. We need FINN to work everywhere it belongs.

Where abstractions begin to matter

The individual platforms still matter because we want to use each of them well.

If a phone is going to act as an observation source aboard a boat, we want access to the capabilities of that phone rather than only the subset that happens to look identical across platforms. On an iPhone, that means direct access to Apple’s location and motion systems, background behavior, local persistence and other native capabilities. A future Android implementation should be equally free to take advantage of what Android does well.

The same principle applies to presentation. A tablet has room for a different helm experience than a phone, while a computer can provide a richer planning workspace. We don’t need to force those experiences into a lowest-common-denominator interface merely to call FINN cross-platform.

Meanwhile, beneath those interfaces we’re already building substantial marine technology. Our work with the IHO S-100 family of marine-data standards is a good example.

FINN’s S-100 implementation isn’t simply code for drawing a chart on a particular screen. We’re building it as a separate Swift package responsible for substantial marine-data decoding, semantics, spatial processing and portrayal. Behind boundaries we control, it already works with technologies written in other languages, including C components, Lua and GEOS-based spatial processing.

There is nothing about that technology that makes it impossible to use with React Native or Flutter. Both provide mechanisms for integrating native code, and modern React Native in particular has made substantial improvements to that boundary.

Our concern is therefore not whether those frameworks can accommodate FINN’s requirements. It’s what happens as more of the difficult work moves through or beneath that boundary.

A conventional cross-platform application may spend much of its life in the shared application layer and occasionally reach into native functionality. FINN is likely to spend an unusual amount of its life close to sensors, spatial processing, native libraries, background execution, marine electronics and operating-system services. As that proportion grows, some of the simplicity that made the higher-level abstraction attractive begins moving elsewhere in the architecture.

We therefore decided not to make the application framework FINN’s primary portability boundary. Instead, we put that boundary around the information FINN understands.

An iPhone and an Android phone don’t need to acquire an observation in exactly the same way. A phone and an NMEA instrument certainly don’t. What matters is that FINN can normalize those inputs into observations it understands while preserving important information about their source, quality and confidence.

Different sources can take very different paths into the system while still describing the same underlying reality.

We abstract meaning, rather than forcing every source to expose the same capabilities.

Swift beyond Apple

This is where Swift becomes more interesting than its reputation as Apple’s programming language might suggest.

Swift now officially supports Linux and Windows, and Swift 6.3 introduced the first official Swift SDK for Android. More important for FINN is how some of that portability works.

Swift code on Android compiles directly to native machine code. The Swift Android team describes its execution characteristics as similar to C and C++ built using Android’s Native Development Kit. Swift still needs interoperability when accessing Android APIs exposed through Java and Kotlin, so this isn’t a magical elimination of platform boundaries. But portable Swift code doesn’t need to become JavaScript, Dart or Kotlin simply to execute on an Android device.

Linux presents another interesting path. Swift can compile natively for x86-64 and ARM64 Linux, and its Static Linux SDK can produce fully statically linked executables with minimal external dependencies.

For ordinary application development, that may sound like an obscure technical detail. For a marine intelligence system, it isn’t. Small ARM-based Linux computers are exactly the kind of inexpensive, capable hardware that can live aboard a boat, giving us a plausible path from mobile devices toward onboard computing without assuming that important FINN algorithms need to be rewritten at every step.

There are important qualifications. We’re not claiming that every Swift package we’ve written today will compile unchanged on every one of those platforms tomorrow. Dependencies have to support each target, platform-specific capabilities still require platform-specific code, and some of these technologies are continuing to mature.

Nor does every component surrounding FINN need to be written in Swift. A cloud service, web interface, native operating-system integration or specialized hardware component should use technology appropriate to its job. FINN already integrates components written in several languages behind boundaries we control.

What interests us about Swift is the amount of core FINN capability that may be able to remain one compiled implementation as it moves among very different classes of hardware.

Portability doesn’t require technological uniformity. It requires stable boundaries.

A cross-platform application architecture can begin with a shared application and reach down into native capabilities when necessary. We’re approaching the problem from the other direction: keep FINN’s portable intelligence as close to native execution as practical, then reach outward to Apple, Android, Linux, cloud services or marine hardware where specialized capabilities are actually required.

Instead of making the application portable and reaching down when we need native capabilities, we’re making FINN portable and reaching out when we need platform-specific capabilities.

How we’ll know whether we were right

It’s tempting to turn native compilation into a sweeping performance claim. We’re not going to.

Flutter’s release applications also compile to machine code on native targets. Modern React Native has substantially improved communication between JavaScript and native code, and demanding shared functionality can be implemented in C++. “Swift is faster” would therefore be both too simplistic and, without measuring our actual workloads, unsupported.

Our hypothesis is more specific. If FINN can keep more of its core processing in one compiled implementation across different environments, we may see advantages in latency, sustained CPU utilization, memory consumption, startup behavior, thermal load and energy use while also reducing the architectural complexity required to achieve them.

Those are measurable questions, and the benchmarks that matter to us look different from many conventional application tests.

We care about what happens while FINN processes observations continuously over a six-hour passage, how much energy location and motion processing consumes, and how quickly vessel state responds when several observations arrive together. We want to understand what S-100 processing costs in CPU time and memory, how the same workload behaves on a phone compared with an ARM-based onboard computer, and what happens when chart information, vessel observations and environmental conditions are evaluated simultaneously.

Eventually, we want to measure the entire path from a meaningful change in the world to a useful insight for the captain and crew. Those results will tell us considerably more about our architectural choices than a synthetic test of how quickly two frameworks render the same list.

There is another kind of efficiency we care about just as much.

Suppose a complicated piece of S-100 processing has been implemented, tested and validated once. If we can take that same implementation to another processor or operating system, that may be more valuable than shaving a few milliseconds from an operation.

The alternative can mean maintaining separate implementations of the same standards-sensitive behavior and repeatedly proving that all of them mean exactly the same thing. That creates duplicated testing, additional opportunities for defects and, perhaps most importantly for an intelligence system, opportunities for the meaning of the data to quietly diverge between platforms.

So our benchmarking ultimately needs to answer two related questions: how efficiently does FINN execute, and how efficiently can we keep FINN consistent as it spreads across platforms?

We have a hypothesis. Benchmarking will give us the evidence, and when we have meaningful results, we’ll publish them.

Choosing for the FINN we haven’t built yet

All of this reflects something basic about boating: boats leave networks.

FINN cannot assume every meaningful operation can travel to a remote server and back before becoming useful. Cloud services can provide synchronization, larger-scale processing, updates and capabilities that genuinely belong there, but observations should be collectable locally, state should be derivable locally, deterministic calculations should be able to run locally, and useful intelligence should remain available when connectivity isn’t.

The cloud should make FINN better. It shouldn’t be what makes FINN work.

In a system that can span several people and devices, the cloud can help plans, vessel information, observations and voyage history move where they’re needed. But the boat shouldn’t stop understanding itself because connectivity disappears offshore. Systems aboard should continue doing the work appropriate to them locally and reconcile what needs to be synchronized when connectivity returns.

A lightly instrumented sailboat may initially give FINN little more than the capabilities of the phones carried aboard. Another vessel may provide a rich NMEA network and dedicated onboard computing. Future capabilities may make more sense running directly aboard the vessel than on either a phone or a remote server, and some may eventually need no screen at all.

We don’t know exactly where every part of FINN will ultimately run. That’s precisely why we care about these boundaries now.

The same is true of the people using it. A captain, navigator and crew member may have different responsibilities and need different information. Shared intelligence doesn’t require identical screens or identical roles. What needs to remain consistent is FINN’s understanding of the vessel, voyage, surrounding environment and the relationships among them.

This is more than cross-device synchronization. The longer-term goal is shared vessel intelligence.

Choosing Swift isn’t a one-time technology verdict. It’s an engineering hypothesis that we now get to test. Our original React-based appliance taught us about separating the interface from the intelligence. Our mobile implementation is teaching us about native sensors, mobile constraints and local operation. Future platforms and onboard hardware will test how well those ideas travel.

Where the architecture works, we’ll extend it. Where it doesn’t, we’ll change it. We’re not interested in defending a programming language; we’re interested in building the right architecture for FINN.

There are easier ways to maximize code reuse between mobile applications, and there are very good reasons other development teams choose them. We’re optimizing for something different.

FINN isn’t an app that happens to know about boats. We’re building a marine intelligence engine that may ultimately live in several places at once while maintaining a coherent understanding of what’s happening aboard.

The hardware will change. The interfaces will change. The available sensors and technology will change. FINN shouldn’t have to become a different intelligence system every time they do.

Our objective isn’t to write one app and run it everywhere.

It’s to:

Build the intelligence once. Deliver it appropriately everywhere.

That’s why FINN chose Swift.

We have some exciting news — FINN has been selected for VentureWell’s Fall 2026 Stage 0 Ocean Enterprise Accelerator!

For an early-stage company, this is a milestone worth celebrating.

We’re incredibly grateful to VentureWell, with the support of NOAA, for selecting FINN to join this fall’s cohort and giving us the opportunity to learn alongside other founders building new technologies for the ocean economy.

Programs like this matter because they give young companies a chance to challenge assumptions, learn directly from customers, work with experienced mentors and sharpen the path from an idea to a real business.

And, frankly, it’s exciting to see FINN recognized alongside a group of companies working on some fascinating problems across marine technology and the blue economy.

We still have plenty of work ahead of us, but this is one of those moments where it feels right to stop for a second and say:

Yeah — we did it.

Thank you to the VentureWell team for believing FINN belongs in this cohort. We’re excited to get started.

You can see the full Fall 2026 Stage 0 Ocean Enterprise Accelerator cohort on VentureWell’s website:

View the Fall 2026 Stage 0 Ocean Enterprise Accelerator cohort

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.