These principles govern how Tessera is designed, built, and maintained. They are not aspirations — they are active constraints that shape every decision we make. We publish them because the people who should use Tessera deserve to know how it was built.
Every number Tessera displays must be one a Controller would put her name on.
This is the sentence that everything else flows from. It is not a product positioning statement. It is an architectural constraint. It means:
Most BI tools are built around the question “what does the data say?” Tessera is built around a different question: “can you stake your professional reputation on this number?” That question has different answers, and it requires a different kind of software to answer it correctly.
Tessera is designed for audit up to and including a public company. This is not a compliance checkbox — it is a design philosophy that manifests throughout the system.
Immutability. Closed accounting periods are immutable in NetSuite. Tessera treats this as an architectural guarantee. Metric results for closed periods are computed once and stored permanently. They are never recomputed from live data, and they are never silently overwritten. The only exception is an Administrative Reset — a tiered override mechanism requiring named authorization, a mandatory documented reason, and a permanent dual-value audit record. Tier 2 resets (soft-closed years) require Controller approval. Tier 3 resets (hard-closed years) require two named approvers. The original result is never deleted — it is marked superseded and retained permanently alongside the replacement. If you need to know what Tessera showed on a given date under a given metric definition, you can reconstruct it exactly.
Versioning. Every change to a metric definition creates a new version with an effective date, a mandatory change note, and a named approver. Historical results are permanently associated with the version that produced them — there is no restatement of prior periods. Every chart that shows a metric over time renders a visible marker at each version boundary. You can see, at a glance, when the definition changed and why.
Full audit trail. Every material change is logged. Every minor change is logged separately, with the previous and new value, who made the change, and when. Nothing is silently modified.
Sign-off as a first-class concept. Metric approval is not an afterthought access control feature. It is a domain concept with its own data model. Approval Domains define areas of responsibility. Each domain has a designated approver — typically a Controller or CFO. No metric is active without a named sign-off from the appropriate domain owner. If that person leaves the company, the approval history is preserved and the domain requires a new designated approver before new metrics can be activated.
Pre-flight verification. Before signing off on a new metric, Controllers step through a verification workflow that ties each component of the metric to a named financial statement line. Discrepancies are noted and stored permanently alongside the approval record. This is the difference between a Controller who glanced at a number and a Controller who verified it.
Tessera runs entirely inside NetSuite. There is no external database, no ETL pipeline, no middleware server, no separate login. The portlets appear on the NetSuite home dashboard. The metric wizard runs as a native NetSuite Suitelet. The data lives in NetSuite custom records. The computation engine runs as NetSuite scripts.
This is not a cost optimization. It is the correct architecture for this problem.
Security. NetSuite’s role-based security model governs every Tessera record and every portlet. There is no separate authentication surface, no token to compromise, no API credential to manage. If a user does not have access to a subsidiary in NetSuite, they do not see metrics for that subsidiary in Tessera.
Data integrity. The system of record is NetSuite. Tessera stores only what NetSuite does not already know — its own interpretations, approved metric definitions, and pre-computed results. It does not duplicate transaction data. It does not maintain a shadow ledger. There is no synchronization problem because there is nothing to synchronize.
Auditability. Because Tessera data lives in NetSuite, it is subject to the same audit controls as the rest of the ERP. NetSuite’s own audit trail covers Tessera records. An auditor does not need to learn a second system or trust a data export from an external tool.
Operational simplicity. There is nothing to install on a server, nothing to patch, no infrastructure to monitor. The platform handles availability, backup, and scaling. A customer who installs Tessera gets a SuiteApp — the same mechanism as any other NetSuite extension.
Tessera’s domain logic — the metric governance model, formula evaluation, versioning rules, approval domain model, query orchestration — is designed to be platform-independent. NetSuite-specific code lives in a bounded adapter layer, separated from the domain by formally defined TypeScript interfaces.
This matters for two reasons.
First, it makes the domain logic independently testable. Unit tests run in Node.js without a NetSuite sandbox. The query resolver, formula evaluator, and versioning logic are covered by a test suite that runs in seconds and does not require any ERP connection. High test coverage on domain logic, combined with platform integration testing in sandbox, is the correct testing strategy for a SuiteApp.
Second, it preserves optionality. If Tessera eventually targets other ERP platforms — and the metric governance problem exists on every major ERP — the domain logic ports as-is. Only the adapter layer changes. The five core port interfaces (IQueryExecutor, IRecordLoader, IResultStore, ICacheStore, IFileStore) define the entire surface area of NetSuite dependency. Everything outside those interfaces is portable.
Tessera maintains a strict separation between the path that defines and computes metrics and the path that displays them.
The write path is the Metric Wizard and the Cache and Refresh Engine. The Wizard produces approved metric definition records. The refresh engine computes results and stores them as pre-computed Metric Result records. This path runs on a schedule and on event triggers — not at display time.
The read path is the portlet. It reads pre-computed Metric Result records. It does not touch metric definitions, does not re-run queries, does not perform any computation. Rendering a portlet is a record lookup.
This separation is what makes the accounting-grade guarantee achievable. A portlet that re-runs a query every time it renders cannot make the “Controller signed off on this” claim — because the number it shows was not the number the Controller reviewed. A portlet that reads a stored, timestamped, approved result can make that claim, and does.
Tessera ships with a comprehensive baseline library of atomic metric components and composed metrics — covering the standard financial and operational metrics a Controller or CFO would expect to find: revenue, gross profit, EBITDA, DSO, DPO, current ratio, operating margin, and the rest.
These baseline components are immutable. They are deployed as part of the SuiteApp and cannot be edited. This is not a limitation — it is the point. The baseline is the authoritative definition. If a Controller’s company calculates revenue differently than the baseline, they fork the baseline component, the fork goes through the standard approval workflow, and both the baseline and the custom version are visible in the Metric Registry with full lineage back to the original.
The result is that every metric displayed in Tessera has a traceable definition, an approval record, and a clear relationship to the authoritative baseline. This is what it means to be the system of record for metric governance, not just a reporting tool.
Tessera’s internal documentation is treated with the same discipline as its code. Every architecture decision is logged with its rationale and explicit version scope. Every technical term has a canonical definition enforced by a prose linter across all documentation. Every document carries structured metadata identifying what it owns and what it references. Every commit produces a structured memo summarizing what changed and why.
This discipline serves the product in ways that are easy to underestimate early. It is what allows a future engineer to understand why a decision was made without code archaeology. It is what allows customer support to be answered precisely from documented decisions rather than guesswork. It is what allows a technical due diligence team to review the architecture without a marathon briefing. It is the foundation that makes scaling possible.
Tessera is developed in compliance with NetSuite’s SAFE (SuiteApp Framework for Excellence) Guide 2026.1 — the technical, security, and compliance standard for SuiteApp certification. SAFE compliance is integrated into the design process, the build pipeline, and the commit workflow from the beginning — not addressed as a pre-launch checklist.
Tessera’s use of NetSuite’s native AI module for metric creation assistance and query conversion is subject to SAFE Section 14 (AI Systems in SuiteApps). Tessera maintains a formal AI policy, performs documented AI risk assessment, and targets the BFN-AI Application certification badge.
Third-party dependency management, OWASP security principles, and open-source license compliance are maintained as continuous obligations, not point-in-time checks.
Tessera is built by people who have worked inside the accounting and ERP industry long enough to understand why trust is hard to earn and easy to lose. These principles are our commitment to earning it.