Docs · limitations
What it does not do, and what nobody has proved yet
You deserve to read the gaps before you install rather than find them afterwards. Everything on this page is taken from the source and the debt register, not from an impression of how finished the product feels.
How to read this page
No pass rate appears anywhere on it. The shipped source holds 27 test codeunits and 484 test methods, and those are counts of what exists, not evidence that they passed on any particular build. Six further tests are written but not merged and not compiled, and they are not in that figure — a test that has never been built is not a test yet. Run evidence is generated per machine and is not published. If you want to see a run, ask, and you get the raw output rather than a number.
"Not covered" means no automated test asserts it. It does not mean it is broken, and it does not mean it works. It means nobody has proved it in a way that survives the next change.
Four of the checks described below — on the API page shape, on the permission sets, on the telemetry events and on the manifest — are written, green and self-tested, but they are still open changes rather than part of the main line. Today they hold the changes that carry them, not the whole repository. Read them as landing, not landed.
Not covered by automated tests
Payment reversal and unapplication
Credit memos are covered. Posted and paid invoice states are covered. What was not covered is a payment that gets applied and then unapplied, or reversed after application. This is 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 are now written: 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. They have not been compiled or run yet — the machine holding the source cannot currently start the AL compiler. Until a build runs them green, count this gap as still open. A test nobody has run proves nothing.
Still not covered even on paper: a payment spread across invoices belonging to two different charters, and application against a credit memo in the same transaction.
The two API pages
No test references either published page. The codeunit behind expense import staging is well covered — promotion, duplicate rejection by external id, validation failure with error detail, correction after rejection, bulk promotion — but no test exercises the pages themselves.
The shape is held by a committed contract instead. Both pages are recorded field by field — publisher, group, version, entity set, source table, write flags, bound actions, and every exposed field with the table field behind it — and a gate on every change reads the shape back out of the source and fails on any difference. It catches the change that used to be invisible: a renamed field, a bumped version, a dropped promote, the read-only charter page made writable, or a field quietly repointed at different data behind an unchanged name. A second script makes each of those breaks against a throwaway copy and fails if the gate misses one, so the gate is not trusted on its own word.
What that does not prove is runtime. The gate reads source, not OData. That the platform serves those names, and that promote behaves for a real integration user, is still proven only by live calls. The API guide says the same thing at the top of the page.
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. It does not prove every real denial a non-SUPER user hits in a live session, because the platform test runner does not reproduce that faithfully. Positive proof is stronger than negative proof here.
Permission sets are gated against the list as it stands
All four permission sets are recorded entry by entry in a committed contract — every object, every access letter, plus whether the set is assignable and which other sets it includes. A check on every change reads them back out of the source and fails on any difference. Adding a table to a persona, widening read to full write, or quietly dropping a grant breaks the build instead of depending on somebody reading a 150-line list carefully. A second check breaks that contract four ways on a throwaway copy and fails if the first one misses any of them.
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 is now frozen rather than flagged, and 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 is now enforced rather than merely intended, and it is 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.
What that is not is immutable storage — a SUPER context can still write to those tables. There is no automated assertion that an evidence trail is intact after an arbitrary sequence of operations.
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 rather than missing
Working, in use, and deliberately shallow for a 0.1.x build.
| Area | Where it stops |
|---|---|
| Vessel and finance master data | Narrow on purpose. Ownership, management company, default dimensions, banking, VAT and legal entity are not modelled. Pilot use decides which of those are genuinely finance-critical |
| Charter pricing setup | MYBA, All Inclusive and Plus Expenses really do drive APA behaviour and template selection. It carries no rates, fee items, payment terms, accounts or pricing formulas. It configures scheme behaviour, not pricing |
| APA expense categories | Table-driven and configurable, with the code as operational truth. The old fixed enum is still stored on entries as a bridge for rows created before the table existed, so two classifications are persisted, one legacy |
| The status log | Old status, new status, timestamp, user. No reason, no source, no comment. Commercial entries carry that depth; the lifecycle log does not |
| Commercial register batching | Every event creates one register and one entry, so from-entry and to-entry always point at the same row. The register number is less informative than it looks |
| Multi-currency review | Forecast and posted truth exist. Deeper variance explanation and accounting-rate visibility do not |
| Partner extensibility | Publisher events exist at several finance transitions, but coverage is not broad. If you plan to extend Trident rather than integrate with it, ask first — the seam you need may not exist |
| Finance review report | The content is truthful. The packaging is not a polished customer-facing finance pack |
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. The five links Business Central shows you — terms, privacy, help, the product page — 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 eight 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 eight events carry is held by a contract
The paragraph above used to rest on somebody remembering it. It is now read out of the source on every change and held against a committed record: the classification and scope of each event, every dimension it carries, and the exact expression each call site hands to it. Widening the classification, widening the scope, adding a dimension, building a value by joining strings together, or logging from anywhere other than the one codeunit that owns telemetry all break the build. So does the catalogue and the code disagreeing, in either direction. A second check breaks that five ways against a throwaway copy — including switching one call from a document type to a document number — and fails if the first one misses any of them.
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
Two reasons. The object affix is two characters and Microsoft wants a three-letter affix registered with them. And the missing Application Insights connection string is an AppSource requirement rather than an optional extra. Neither affects a per-tenant pilot install.
One remaining compiler diagnostic
An information-level diagnostic on the commercial register's minimum and maximum entry-number fields. Not a warning, does not fail the build gate, not an AppSource blocker. It is listed so nobody finds it and wonders what was hidden.
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, and one known error — the establishment and governing-law clauses — is flagged in the terms themselves rather than 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.
- The payment unapplication and reversal tests get compiled and run green, because they sit under paid-invoice truth. The tests are written; nothing has built them yet.
- The two API pages get one live OData round trip against a running environment. The declared shape is now gated against a committed contract, so a silent rename cannot ship; what is left is proving the platform serves it.
- The licence review comes back, and the pilot agreement draft comes back with a governing-law clause in it.
- 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.