Reference

Release notes

This documentation describes VLDTION 0.6.0, 0.6.0 release candidate. The version shown here, in the application, and in every export comes from one place, so a working paper always names the build that produced it.

0.6.0: installers, rate register, subledgers, completion

Real Linux installers. A .deb, an .rpm and an AppImage are built from this source, and the .deb was installed, launched, uninstalled and reinstalled. With the workspace database surviving the uninstall, which is the correct behaviour.
The whole engine was run with no network namespace at all: no interface, no route, no DNS. All 419 tests passed, and the installed application launched and ran under the same conditions.
A local rate register. The accountant imports a published rate table; VLDTION records the authority, the publication, the dates, the quote convention, a fingerprint of the rates and who imported it, and every conversion that uses one names it. VLDTION still fetches nothing.
Exact dates only: no rate is carried across a weekend, interpolated, or crossed through a third currency. A date the table does not cover is insufficient data, and the run names which dates it could not cover.
Subledger reconciliation. A debtors or creditors ledger is imported as its own dataset with a role the accountant declares, and reconciled against the general ledger through the same matching engine, with both fingerprints on the run.
Five pairing refusals, checked before any amount is read: different clients, different engagements, the same dataset twice, a dataset never identified as a subledger, and a subledger in the ledger slot.
Engagement completion derived from stored state. Nine requirements, each a question about what the engagement actually holds. Completion is refused while anything required is unmet. And an override does not mark a requirement met: it stays unmet, shown as overridden, with who, when, why and the prior state on the review trail.
A working-paper index. Every document VLDTION produces is recorded with the datasets, runs and methodology versions behind it, and each is marked traceable, data-changed or data-absent against what the workspace currently holds. A paper is never re-pointed at data that arrived after it.
The download page is generated from the artefacts themselves: per platform, either files with their SHA-256 and signing state, or a stated reason there are none. Nothing is signed, so nothing is published.
The website now says plainly what it is. The application carries a banner whenever it is running in a browser rather than installed, because a demonstration is not the product.

0.6. Currency, control accounts, carry-forward

Money is held as integer minor units and compared as integers. An amount without a currency is no longer an amount: two figures are only compared when their currency is known and either identical or reconciled through a rate the data carries.
Foreign-currency reconciliation. A converted match shows the original amount, the rate, where the rate came from, the arithmetic and the difference that remained. There is still no confidence percentage.
VLDTION does not fetch exchange rates and will not. A rate comes from the statement, from the ledger posting, from a record carrying both amounts, or from a named reviewer. And a pair with no rate anywhere is reported as BANK-007 rather than matched or dismissed.
Control-account reconciliation: a control balance against the records that support it, through the same matching engine, with five exception rules that explain the composition of the difference rather than only stating it. An account the data cannot support returns insufficient data, never agreement.
Engagement carry-forward. The next period inherits bank scope, mappings, rule configuration, control scopes, reviewer and known counterparties, and inherits no transaction, no bank movement, no finding and no run. Both columns are shown before anything is created.
A suppression is carried as an explanation, not as a decision: the rule runs again and the earlier reasoning appears beside the new finding.
The withholding rate is now encoded and RULE-WHT-001 is verified. 20% under תקנה 2(א) and 30% under 2(ב), from a Supreme Court judgment the Tax Authority publishes; withholding above the statutory maximum is reported, and anything below the ordinary rate is insufficient data because a reduced-rate certificate appears in no export.
A new assurance state, practice-backed, for a rule whose objective an auditing standard supports but whose method it does not prescribe. BANK-001, BANK-002 and BANK-006 cite תקן ביקורת (ישראל) 500 and say in terms what it does not cover.
Scoped queries now filter on the engagement as well as the client, because a client can have several periods once one has been carried forward.
Working papers carry the control reconciliation, the carry-forward, and a reproducibility block: application, rule set, configuration fingerprint, both data fingerprints, the matching, currency and control methodology versions and the evidence schema.
No installer exists for this version: the build machine's Application Control policy now blocks cargo's build-script executables in every target directory tried. The download page and the release manifest say so and name the version the artefacts on record actually are.

0.5: bank reconciliation, clients and engagements

Bank statements import from the spreadsheet or delimited file a bank already produces, with columns recognised in Hebrew and English, three amount conventions read rather than assumed, and every rejected row named.
A deterministic matching engine pairs bank movements with ledger postings in passes, amount and reference, amount and date, amount within the date window, and refuses to choose between equally good candidates.
A match states the facts that produced it. There is no confidence percentage anywhere in the reconciliation.
Six reconciliation exceptions (BANK-001 to BANK-006), each specified with its evidence and with what it does not prove.
Balance continuity is checked where the statement carries balances, and reports insufficient data where it does not.
Manual links record who made them, when, why, and the automatic state they replaced, and survive a re-run.
Clients and engagements: everything stored belongs to a client, every scoped query filters on it, and a reconciliation across two clients is refused.
A portfolio screen with counts per engagement, and archiving that hides without deleting.
Backup covers clients, engagements, statements, reconciliations and manual links, and can export a single client with nothing of any other.
Withholding research: the rate regime ships empty on purpose, and RULE-WHT-001 reports insufficient data rather than encoding a figure that could not be verified. RULE-WHT-002 is verified against the uniform-file specification.
A release manifest generated from the artefacts a build actually produced, with sizes, SHA-256 digests and a signature check read from each file.

0.4. Real accounting exports, cross-period forensics

BKMVDATA is read field by field: the Tax Authority specification 1.31 was retrieved from gov.il and transcribed, and a layout only loads if its fields tile every record exactly and total the length the specification declares.
Uniform-structure documents and journal entries become ordinary VLDTION transactions, with provenance down to the record, the field, the columns and the characters that were in them.
Hashavshevet MOVEIN imports are supported: the data file is read against the MOVEIN.PRM that accompanies it, never against an assumed layout, and the interface carries the allocation number.
Priority has no public export specification; the route for Priority data is the uniform file it is required to produce, and that is stated rather than papered over.
Rules declare the fields they need. A rule whose field an export does not carry reports insufficient data. Never a pass: and the import screen lists those rules before the import runs.
A materiality engine places every amount against the account, the period, the median of its own document type and the period before, with the arithmetic printed alongside. No score.
Four cross-period forensic rules: period-end manual journals, a new counterparty that is immediately material, a dormant account reactivated, and the same period-end adjustment repeated.
The period comparison adds changed findings and measured differences between the two periods.
The investigation screen leads with why the rule fired, then context, then the source record and field, then a timeline that says when the source carries no times.
Dispositions (including awaiting client and no action required) and an append-only review trail, both printed on the working paper.
A local reviewer name for working papers, which is configuration and not authentication.
The evidence bundle is vldtion.evidence.v2: additive, and a v1 reader can still read it.

0.3. Israeli rules, uniform files, working papers

Two rules are now verified against documents published by the Israel Tax Authority: the allocation-number regime and the standard VAT rate. Each carries its authority, publication date and retrieval date into the product and into every export.
Rules declare an assurance state, verified, development, experimental or deprecated, shown everywhere a rule appears. Historical runs keep the rule version that produced them.
Rules report five result states rather than two: pass, finding, not applicable, insufficient data and unsupported. A rule that could not reach a conclusion says so instead of passing quietly.
BKMVDATA is a first-class format: detection, record classification, structural validation against the file's own declared totals and sequence, windows-1255 decoding, and record-level provenance. Field-level extraction is explicitly unsupported in this build rather than guessed at.
Imports show the detected format and the detected accounting period, and the period can be confirmed or set by hand; whether it was detected or entered is stored with the dataset.
The transactions table is virtualised over SQL windows and holds up at 100,000 records and beyond; a benchmark harness records the numbers.
Period comparison across runs of the same client: findings that appeared, resolved or recurred, with counterparty continuity.
Working papers: executive summary, rule coverage, authorities, evidence, review record and an integrity block carrying the fingerprint, run identifier, rule-set version and application version.
Workspace backup and restore as a single local JSON file, with migration tests covering older databases.

0.2: Real data, local persistence, desktop foundation

CSV and XLSX import with column mapping, Hebrew and English header aliases, and row-level normalisation errors.
SHA-256 dataset fingerprinting over the normalised records, independent of file name, size and timestamp.
Local SQLite persistence with append-only migrations, behind one driver port: a file on the desktop, WebAssembly in the browser, in memory in tests.
Run history, persisted finding statuses, notes and suppression, and evidence export as printable HTML, JSON and CSV.
Desktop shell architecture with a capability allow-list and a strict content security policy.

0.1: Foundation

The design system, the marketing site and the application shell.
The deterministic rule engine, the finding and evidence model, and synthetic demonstration data.