Frictionless Table Schema as the contract
Frictionless Table Schema as the contract
In BusDK, each table has a corresponding Table Schema that declares fields, types, constraints, and structural metadata. In the preferred default layout, tables are stored as CSV and schemas are stored as JSON, but the invariant is the schema-driven data contract — not a particular serialization format. Table Schema supports declaring required fields, minimums, patterns, primary keys, and foreign keys. The schema functions simultaneously as documentation, as automated validation input, and as a mechanism for keeping revisions interpretable as tables and schemas evolve over time. See Schema-driven data contract (Frictionless Table Schema) and the upstream specification at Frictionless Data Table Schema.
Any alternative storage backend must preserve these Table Schema semantics, including primary keys and foreign keys, and must be able to export back to the canonical CSV plus schema representation.
Because Table Schema is standardized, modules can share a single interpretation of datasets even when implemented in different languages. Validation can be performed by integrating Frictionless-compatible tooling or libraries, but BusDK’s architectural requirement is that validation behavior is consistent across modules regardless of implementation language.
Shared implementation is allowed for mechanical concerns like schema parsing, CSV I/O, or the workspace store, but interoperability remains defined by datasets and schemas, not by internal Go APIs. CLI-to-CLI dependency is not an integration mechanism — the bus dispatcher provides a unified UX while module implementations remain independent — and the canonical repository layout and dependency rules are defined in Module repository structure and dependency rules. BusDK extends field descriptors with formula metadata (field.busdk.formula.*); the mapping from this metadata to BFL options and the delegation contract are described in Formula metadata and evaluation for workbook extraction.
Audit-trail constraints
To satisfy Finnish audit-trail requirements, Table Schemas MUST formalize the identifiers and links required for traceability. See Finnish bookkeeping and tax-audit compliance.
Primary keys MUST be declared for core datasets (journal, ledger, vouchers, invoices, bank, attachments), and foreign keys MUST be declared for all cross-dataset references (voucher → entries, entries → reports, invoices → attachments). Required fields MUST include the minimum voucher metadata and posting metadata needed for traceability (date, identifier, amount, VAT data when applicable).