What it does not do, and what nobody has proved yet

---

Problems the tests found

Two, both in the same area of the product, both found by a test that went red before anyone had an opinion about it, and both fixed. No build without the fixes has ever gone out to a pilot. Three more problems, found a different way, are below these two.

An undone payment leaves the charter saying Paid

Payment unapplication was the largest single test gap in the product, and it sits directly on the paid-invoice truth that closeout readiness derives from. Six tests for it were written on 1 August 2026. They post real invoices, pay them through a real payment journal, unapply the payment, re-apply it, and reverse it, checking the schedule line, the document link and the closeout status at every step. Two of the six cover the mixed case, one payment closing two invoices and one payment clearing one invoice and only part of another, because a fix that only corrected the invoice you touched would look right and be wrong.

On 5 August 2026 they ran for the first time. Three passed and three failed. After a payment is unapplied, the charter payment schedule line stays Paid when it should fall back to Posted. Business Central does its half correctly: the customer ledger entry reopens, and Trident's own check agrees the invoice is no longer fully paid. Both of those are asserted before the failing assertion and both pass. What never happens is the write that moves the line back.

What it would have cost. A charter could read as paid while its invoice was still open. Nothing warned anybody, and a closeout decision taken on that screen would have been taken on a wrong number. No data was lost and nothing was unrecoverable. Pressing Sync Paid Invoices on the charter corrected it immediately. But nobody was told to press it, and until somebody did, the finance surface was wrong.

Why this is the product and not the test. The run separates the two by itself. The three tests that pass call Sync Paid Invoices by hand after unapplying. The three that fail wait for Trident to notice on its own. One of the passing tests checks the exact same Posted status that two of the failures check, in the same run, and passes. So the code that demotes the line is right, and the thing that is meant to trigger it after an unapplication does not fire.

Where it stands. Fixed, and proved by a run. The fix was written the same evening the tests went red, and at 23:42 that night the same six tests were run against it and all six passed. The three that changed are the three that had failed, and the test file was not edited between the two runs, which is the only reason the second result means anything.

Why it is still on this page. Not because anyone can meet it. The fix is in 0.1.0.30 and every build since, and no build ever went out to a pilot, with or without it, so the defective code has never run outside the build environment. It stays because this page is the record of what the tests caught, and a page that dropped each defect once it was fixed would only ever describe a perfect product.

What was still not known, and now is. Three neighbouring cases were untested in either direction until the evening of 6 August 2026, when their tests ran for the first time: unapplying an APA settlement payment and unapplying against a closed charter both demote correctly, and the third answered a question nobody had. A reversal with no unapplication before it cannot happen. Business Central refuses to reverse a payment that is still applied, full stop, so the feared route around Trident's bookkeeping does not exist, and a test now stands guard on that refusal in case a platform update ever opens it.

A payment posted through the journal never marks the charter paid

Found on 6 August 2026, the only failure in a whole-suite run against 0.1.0.26. The test does the ordinary thing: build a charter payment schedule line, invoice it, post it, then pay the posted invoice through a payment journal the way a finance team pays anything. Business Central closes the invoice, and Trident's own check agrees the invoice is fully paid. Both of those are asserted before the failing one and both pass. The schedule line never moves off Posted.

What it would have cost. The mirror of the defect above, and the more likely one to be met, because paying an invoice from the payment journal is the normal route and unapplying one is not. A charter read as unpaid after the money had arrived. Nothing was lost and nothing was stuck. Pressing Sync Paid Invoices on the charter fixed it at once. But until somebody did, the charter looked behind on money it had already been paid, which is the kind of wrong number that gets chased.

Why this is the product and not the test. The neighbouring test runs the identical sequence and calls Sync Paid Invoices by hand, and it passed throughout. The code that marks the line paid was never wrong. What was missing was anything calling it on this route.

Why the earlier fix did not cover it. The two defects look like one and they are not. The fix for the unapplication defect hooks the part of Business Central that runs when somebody uses the Apply Entries action against entries already posted. A payment journal line that carries an application does its applying somewhere else entirely, while the payment posts, and never reaches that code at all. The first fix was not late or mistimed. It was on a road this scenario does not drive down.

Where it stands. Fixed, and proved by a run. The charter now registers a payment from every route a payment can arrive by, whichever screen or journal drove it, and the change can only ever mark a line paid, never unpaid. The whole suite was re-run against the fix instead of the one test, and every test passed.

Why it is still on this page. Same reason as the one above. The fix is in 0.1.0.30 and every build since, no build without it ever went out to a pilot, and the record of what the run caught stays.

---

Problems found by reading the code, not by a test

These three are kept apart from the ones above on purpose. Those were caught by a test that went red before anybody had an opinion about it, which is the stronger kind of evidence. These were caught by reading the code, and a defect somebody noticed is a weaker claim than a defect a machine reported. Putting them under one heading would make the measured list look longer than it is.

The second company you create gets nothing

Trident writes its setup record, its ten expense categories and its three pricing schemes into each company when it is installed there and again when it is upgraded. Neither of those happens for a company you create afterwards. That company came up empty, and empty is not cosmetic: the first person to price a charter in it got Charter pricing setup is missing and could go no further. Running more than one company in a Business Central tenant is ordinary, so this was waiting for the first pilot with two.

What it would have cost. Charter pricing did not work at all in the new company until somebody noticed. There was no data loss and nothing to unpick, but there was also no obvious cause on screen, and the natural reading was that the extension was broken, not that one company was never set up.

Where it stands. Fixed in 0.1.0.28. The seeding now lives in one place with three ways in: install, upgrade, and the moment Business Central creates a company. The duplication that let the third route go missing is gone, and five new tests cover it, one of which asserts the failure itself in both directions, so the error appears in an unseeded company and stops appearing once the seeding has run.

What was watched, and what was not. The per-company setup was watched running to completion in a company that had never held a single Trident record, so nothing else could have filled it in. What was not watched is the Create New Company screen driving it end to end, which needs a piece of test infrastructure that is still being put in place. That single step is the one box still open on the install checklist.

Why it is still on this page. Same as the two above. The fix is in every build since 0.1.0.28, nothing older ever went out to a pilot, and the record stays.

A charter statement can print an expense category that is blank

The APA statement is the document a guest settles against at the end of a charter. Every line on it carries a date, a description, an amount and the category the money went on. An entry written before the category list became something you maintain yourself carries the old fixed category and nothing else, and the statement copied the two category fields straight off the entry instead of asking the entry what they mean. On such an entry both of those fields are empty. A guest would have got a real amount with an empty box beside it.

What it would have cost. The most customer-facing document in the product going out looking unfinished, and somebody explaining a line by hand at the exact moment a guest is being asked to pay it. Nothing was lost and no number was wrong. It was the label that was missing.

Why the obvious fix on its own would have been worse. The entry can work its category out from the old value, and that is what the statement now asks it to do. An entry nobody ever categorised has no old value either, and the code that works it out falls back to the first category in the list, which is Provisions. Repairing only the statement would have swapped a visible blank for a confident wrong word on the same line, with nothing on the page to say it was a guess. So marking an entry reviewed now fails while that entry has no category, and the error names the entries that need one. A statement only ever includes reviewed entries, so the blank cannot reach a guest at all.

What the guard changes in use. Reviewing a batch of APA entries that have no category fails where it used to go through. That is the guard doing its job. The error lists the entry numbers, they take a category, and the batch goes through.

Where it stands. Fixed in 0.1.0.30, with seven new tests. Two hold the statement, one on a legacy entry and one on an ordinary entry so the normal path is proved untouched. Two hold the review guard in both directions, refusing the entry without a category and accepting the same entry once it has one. Three hold the upgrade step that fills these categories in, which had never been testable before, because it sits behind a marker that by design runs once and then never again.

What is not proved. No real tenant's data has been through that upgrade step. It ran for real here, across both companies on the test tenant, and neither company holds any pre-category entries, so it ran over nothing. The behaviour is proved by three tests that build the old state deliberately. It is not proved by watching a real migration, because there has not been one.

Deleting a charter left its money behind

A charter can be deleted. Until 0.1.0.30 the only thing that stopped a delete was a payment line that had already been processed, so a charter whose lines were all still planned went through cleanly while it still held APA expenses, an issued settlement statement and commercial entries. Business Central does not clear those for you, and nothing in Trident reads them through the charter. Nothing failed and nothing warned. The rows stayed in the database naming a charter that no longer existed.

What it would have cost. Charter numbers come off a number series or are typed in, so a freed number can be issued again. The next charter to take it inherits the previous charter's expenses and the previous charter's settlement statement, on the finance pages and on the document a guest settles against. Orphaned rows on their own stay recoverable while nobody has noticed them. The reused number is the part that puts a wrong figure in front of somebody.

Where it stands. Fixed in 0.1.0.30. The delete now refuses separately on APA ledger entries, on settlement statements and on commercial entries, and the message says which one is in the way. A charter that is allowed to go now takes its own status log, review history and document links with it; those were being orphaned by the same gap. Six new tests cover all six behaviours.

What the guard changes in use. Any housekeeping that deletes finished charters in bulk fails on exactly the charters it should never have deleted. That is the guard working. Charters deleted under an earlier version cannot be repaired, because nothing recorded that the parent had gone.

What the guard does about the past: it finds, it does not fix. Rows orphaned before the guard existed survive the upgrade untouched, and until build 0.1.0.32 nothing in the product went looking for them. The setup health screen now does: a warning row counts every expense record, settlement statement and audit record whose charter no longer exists, with the three counts shown separately. It warns, never blocks, because these rows arrive from a version you have already left and stopping your setup over them would help nobody. The cleanup itself is still by hand, list by list, and the row shows totals, not which charter numbers are affected. Five tests cover the row, green in the run at the top of this page.

What is not proved. The guard was exercised only against charters the test suite created. Nobody has deleted a charter in a tenant that has been used. The reused-number consequence above stopped being a reading of the code on 6 August 2026: two tests now build it deliberately, handing a deleted charter's number to a new charter and watching it inherit the old expenses and settlement statement. Both are green in the run at the top of this page.

---

Not covered by automated tests

The rest of payment unapplication

Closed. The four cases the six tests above did not cover each got a test on 6 August 2026, and all ran green that evening: a payment spread across invoices belonging to two different charters demotes both, a credit memo closing an invoice in the same transaction does not count as payment, an unapplied settlement payment demotes the settlement link and blocks closeout, and a closed charter still reports the outstanding payment in review. The fifth case, reversal without a preceding unapplication, turned out not to exist: the platform refuses to reverse an applied payment at all, and the test now asserts that refusal.

The two API pages

No test references either published page directly. The logic behind expense import staging is well covered: promotion, duplicate rejection, validation failure with error detail, correction after rejection. What nothing exercises is the pages themselves.

The published shape is held by an automated check on every change instead: a renamed field, a bumped version, a dropped promote action, or the read-only charter page turning writable fails the build before it can reach a tenant. What that cannot prove is runtime.

What that does not prove is runtime. The gate reads source, not OData. So on 1 August 2026 the pages were driven over HTTP the way an integration would drive them, and the two things worth knowing both held. The platform serves exactly the field list the source declares, checked one name at a time. And promote works end to end: a staged expense goes in, comes back with a real ledger entry number against it, and calling promote a second time on the same row does not post it twice, which is the one that matters, because any integration will eventually retry. Nineteen checks, all nineteen green.

That first run was done by hand, against one company, as an administrator. On the evening of 6 August 2026 it was repeated as a script anyone can re-run, 25 checks this time, and as a deliberately restricted user instead of an administrator, because an administrator's session answers yes to everything and proves nothing about what an integration is actually allowed. All 25 passed, and one of them is new knowledge: the API user is refused when it tries to delete its own staged rows, which is the append-only rule holding at the interface, not just in the declaration. What is still open is repetition: nothing runs those 25 checks automatically when the pages change, and until something does, this stays listed. The API guide says the same thing at the top of the page.

If you are integrating, one thing that run surfaced will save you a bad afternoon: promote answers with success even when it decides the row is a duplicate and declines to post it. Do not trust the response code. Read the row's status back after the call.

Negative permission denial

Runtime persona testing proves Admin, Ops and Read can each do what they are meant to do, and proves the static grant boundaries. What it did not prove was the refusal. Those tests ask Trident's own access guard whether a persona is allowed in, so a guard that stopped being called, or a permission set that quietly picked up a letter, would have left every one of them green.

Fourteen new tests cover the half of that a permission mock can cover. Each one runs a bare table write from a session holding one Trident permission set and nothing else, so the refusal has to come from Business Central and not from Trident. Read cannot create, change or delete a charter, add an APA expense, touch a payment schedule line or edit setup. Ops cannot edit setup, which is the single grant separating Ops from Admin. And nobody can change or delete a row of the audit trail, Admin included, which is the one that matters most. Two of the fourteen are deliberately positive, because a suite made only of refusals passes just as well when the mock is over-restricting as when the permission sets are right.

All fourteen ran green on the evening of 6 August 2026, and the first run sharpened two of them: in both cases the platform refused more precisely than the test had predicted, and the tests were corrected to match the stricter behaviour, which is the boundary working better than expected.

What is still not covered either way is a denial that only shows up through a page or a button in a live session. No amount of mocking reproduces that. It needs a browser that can reach a running environment, and that route is closed here.

Permission sets are gated against the list as it stands

All four permission sets are held by the same kind of automated check: a grant added, widened or quietly dropped fails the build instead of depending on somebody reading a long list carefully.

What that proves is that nothing changes without being seen. It does not prove the current list is right. The contract was written from the sets as they are, so anything already too broad has been frozen in place. The gate will never flag it. Only a review by someone who knows the finance workflow will find it.

Evidence integrity is not asserted end to end

Commercial entry and register pages are read-only, and no assignable permission set can modify or delete either evidence table. That used to be an intention and is now enforced, checked against what a persona ends up with after inherited sets are resolved, so nothing can widen it through the back door. Ops and Admin can add entries, which is what an append-only trail needs, because entries are written in the acting user's own session. Five of the permission tests above go further and try the edit for real, from each persona in turn, so the boundary is measured and not just declared.

The other half of this was the trail itself. A single logged event was covered. Whether the whole trail for a charter survives everything that happened to it was not, and that is the question somebody reviewing a disputed charter actually asks. Five new tests drive an eight-event charter life and then check the properties the trail is meant to hold as a whole: every event still there, still in order, every entry attached to a register that admits owning it, and a second charter running through the same eight steps without its events leaking into the first.

Those five ran green on the evening of 6 August 2026. What none of it is is immutable storage. A SUPER context can still write to those tables.

---

Deliberately out of scope

Scope decisions, not gaps. Trident is a finance layer for charter billing and APA, and it stays that.

• No maintenance or planned-maintenance system.
• No crew HR, payroll or crew operations.
• No owner portal.
• No PMS, procurement, inventory or technical management.
• No compliance module.
• No generic workflow engine and no generic audit framework.
• No attempt to replace an all-in-one yacht platform.
• No AI-first positioning and no AI-driven automation.

Business Central stays the accounting backbone. Trident keeps no parallel ledger; posting, permissions and audit evidence stay where Business Central puts them.

---

Thin on purpose

Working, in use, and deliberately shallow for a 0.1.x build.

---

Technical and packaging limits

Debugging is enabled

The extension allows debugging, so an administrator with the right rights can attach the Business Central debugger and step through Trident code. Source downloading is off and source is not included in the symbol file. This is a deliberate pilot-time setting, not an oversight, and all three settings are held against a committed record so none of them can be turned back the other way without the change being seen.

The manifest is held to what it says here

Two of the claims on this site are things you have no way to check for yourself: that Trident makes no outbound network calls, and that no Application Insights connection string is configured. Both are now enforced on every change. Any HTTP type appearing anywhere in the source fails the build, and so does any Application Insights key appearing in the manifest. Terms, privacy, help and the product page are among the five links Business Central shows you, and all five have to stay on a host under Marvera's control over https, and internal objects may not be exposed to another publisher's app.

The figures a customer installs from are checked the same way. The version, the app id, the minimum base application, the runtime and the object range on the install page are read out of the manifest and compared with the runbook in both directions, so a version bump cannot leave a stale number on a page somebody is planning an install window from.

No telemetry reaches Marvera

Trident emits nine telemetry events, all classified as system metadata and all at publisher scope. What they carry is a component name, an operation name, a result, and one of a counted number, a document type, a closeout status or a blocked reason. No customer names, no document numbers, no amounts, no vessel codes, nothing anyone typed. No Application Insights connection string is configured either, so publisher-scope telemetry currently has nowhere to go. In practice: nobody here can see that your install is struggling. If something is wrong, tell me, because I will not find out on my own.

What those nine events carry is held by a contract

The paragraph above used to rest on somebody remembering it. It is now checked automatically on every change, so widening what telemetry carries, or the description here and the code drifting apart, fails the build instead of reaching you.

What it cannot do is read types. Without compiling, a document type and a document number are the same shape on the page. What it can do is refuse to let either one change quietly, so that judgement lands on the one line that matters instead of passing unread in a finance diff.

Not submittable to AppSource as it stands

One reason left. AppSource requires an Application Insights connection string, and there is none here on purpose; over there it is not optional. The other reason went away on 12 August 2026, when Microsoft registered a three-letter affix to Marvera and every object in the product was renamed onto it in build 0.1.0.34. That rename changed no behaviour and no test. Neither reason ever affected a per-tenant pilot install.

Three remaining compiler diagnostics

This heading said one until a build was run on 1 August 2026 and emitted three. All three are information level: one on the entry that lets the test app see the product's internals, and two asking that a calculated field be added to a lookup key, on the commercial register's entry number and on the charter's amount in charter currency. None is a warning, none fails the build gate, none is an AppSource blocker.

The build around them is clean: no errors and no warnings, with the compiler set to treat any warning as a failure and all three of Microsoft's analysers switched on. The three are listed here so nobody finds them and wonders what was hidden. The count now comes off a build instead of somebody's memory.

---

The commercial position, stated plainly

Not product limitations, but they belong on the same page as everything else you should know before signing.

• The licence terms have not been reviewed by a lawyer. They say so on their own first line. A review brief has been prepared for a Dutch IT/IP lawyer. One known error, in the establishment and governing-law clauses, is flagged in the terms themselves instead of being quietly left there.
• The pilot agreement is a draft nobody has reviewed. The EULA is a product licence: it names no term, no tenants, no fee and no end-of-pilot data handling. A draft that does all of that now exists, written by me and not by a lawyer. Its governing-law clause is deliberately empty and its liability clause points at the EULA, which is itself unreviewed. Nothing gets signed until both come back.
• The support process is a placeholder. What exists is real and small: an email address, acknowledgement inside two business days, security reports handled confidentially and first. No committed resolution time, no service level.
• Nobody has installed Trident in production. Not one customer, not once.

---

What has to change before anyone pays

Short list, in the order that actually blocks money changing hands.

1. The suite is green, and the run that proves it goes against a build a customer can install. Most of the way there, and the two halves finally point at the same build. On the night of 12 August 2026 one run covered every method in the source and came back with all of them passing, every problem on this page fixed, and that same build was the one packaged. The file a pilot would be sent is named and fingerprinted at the top of the install runbook so it can be checked on arrival. What has not happened is the arrival: the next pilot delivery has not gone out, the install has never been driven from the Create New Company screen outside the build environment, and the package is unsigned. No earlier build went out either, so the first install a pilot runs will carry every fix on this page.
2. The two API pages get one live OData round trip against a running environment. Done twice, and the second time answered the harder question. On 1 August 2026 nineteen checks went green against a running environment, driven by hand as an administrator. On 6 August 2026 the same ground was covered again by a script, 25 checks this time, as a deliberately restricted user, and all 25 passed. What is left of this one is nothing but repetition: no branch or nightly job re-runs those 25 checks when either page changes, so the platform is known to serve the declared names as of one evening and not as of the current build.
3. The licence review comes back, and the pilot agreement draft comes back with a governing-law clause in it.
4. Live non-SUPER sign-off evidence for all three personas in a controlled tenant.

Everything else on this page can wait for a pilot to tell us whether it matters. Status tracks which of the four have moved.

---

If a gap here is the one that decides it for you, say so: [email protected]. Pilot feedback is what reorders this list.