Immutable audit trail
Every transformation is appended to a tamper-evident ledger the moment it happens. No user, process, or agent, including Loktak itself, can modify or delete a record once it's written.
Loktak is the reason InSightOS outputs are defensible. Here's what that means for the VP Finance presenting to a board, not the engineer building the pipeline.
Every number InSightOS shows is produced by Loktak running a deterministic, rule-based pipeline on your actual source data. If someone asks where it came from, Loktak can trace it back to the specific source row, transformation rule, and timestamp that produced it.
Loktak resolves cross-system conflicts before InSightOS ever reads the data. When systems disagree, it applies your configured resolution rules, produces a single canonical number, and logs that logic so the alignment debate ends at the data layer.
Loktak writes immutable provenance for every value: source system, transformation applied, timestamp, pipeline version, and the rule used. InSightOS logs the decision on top of that, so the full chain from raw ledger row to approved reforecast is exportable as a structured audit trail.
Your allocation logic, elimination methodology, and finance-specific heuristics live in Loktak's versioned knowledge library. Update a rule once and every downstream InSightOS output reflects the new logic, while the previous version stays preserved for historical comparison.
Loktak runs signal integrity checks before analysis begins. Duplicate rows, missing periods, format inconsistencies, and out-of-range values are flagged before they can turn into a number you present to the board.
Loktak is the strict boundary between your raw data sources and the InSightOS execution layer. Nothing crosses that boundary without being resolved, normalised, versioned, and lineage-stamped first.
For the full component boundaries, API surface, and what each layer is and isn't allowed to touch, see the technical documentation.
Every Loktak pipeline run moves through the same eight stages in order, and each one has to clear a data-quality bar before the next begins. If something falls short, the pipeline halts. InSightOS never reasons on data that hasn't been verified.
Loktak connects to each configured source system via its native API or SFTP export. Format parsers normalise CSV, JSON, Parquet, and native ERP export formats into a staging schema. Schema validation runs against expected column types, required fields, and referential integrity rules before any further processing begins. A source that fails validation halts the pipeline. No partial data passes forward.
For stage-by-stage mechanics, validation thresholds, failure behavior, and a full pipeline run log, see the technical documentation.
Your organisation's specific finance intelligence lives not in a spreadsheet, not in someone's head, and not in undocumented model logic. It is encoded in Loktak, applied to every pipeline run, and versioned permanently.
Rule DSL syntax, YAML examples, LoRA-based encoding, and feedback-loop mechanics are in the technical documentation.
Every value InSightOS shows links back through Loktak's append-only ledger to the source row it came from, every transformation applied along the way, and the decision it informed. Nothing in that chain can be modified or deleted, not even by Loktak itself.
Every transformation is appended to a tamper-evident ledger the moment it happens. No user, process, or agent, including Loktak itself, can modify or delete a record once it's written.
The same ledger that records Loktak's transformations also records the InSightOS decision that used the result, so the full chain from raw row to approved action lives in one place.
"Where did this number come from" is a lookup, not a project. Full chains export in one click for auditors, board decks, or a skeptical Sales VP.
lineage_for() query examples, comparative lineage between pipeline runs, and decision-layer integration details are in the technical documentation.
SOX compliance, data residency, role-based access, and audit readiness are design constraints that shaped Loktak's architecture from the beginning, not features added on top.
The lineage ledger and decision log together produce a complete SOX-compatible audit trail. Every transformation, business rule, analyst decision, and approval is timestamped, attributed, and tamper-evident. Exportable as machine-readable report or human-readable PDF for external auditors.
Loktak can be deployed entirely within your private VPC or on-premise infrastructure. Your financial data never leaves your environment. Full residency controls for GDPR, SOX, and sector-specific requirements.
Granular access control at the account, entity, period, and metric level. A salesperson sees pipeline metrics but not COGS. An analyst sees their region's P&L but not the consolidated group. Policies encoded in Loktak, enforced across all InSightOS outputs.
All data at rest encrypted with AES-256. All data in transit uses TLS 1.3. Keys managed via your configured KMS, including AWS KMS, Azure Key Vault, GCP Cloud KMS, or self-hosted HashiCorp Vault.
No autonomous changes to source data, financial models, or downstream systems without explicit human approval. Loktak processes and InSightOS recommends, but every downstream action requires a named, authenticated user. The approval is logged with approver identity and data version.
Retention policies configurable per data category. Lineage records: 7 years default. Raw source snapshots: 13 months. Canonical object versions: 7 years. Regulatory hold policies can override. All retention operations logged.
| Compliance requirement | Typical AI finance tool | Loktak |
|---|---|---|
| SOX audit trail | ||
| Data lineage to source | ||
| Private deployment | ||
| Rule versioning | ||
| Human approval gate | ||
| Tamper-evident storage | ||
| RBAC at object level | ||
| Configurable retention |
Pre-built connectors handle authentication, pagination, incremental sync, and schema mapping for every major ERP, CRM, and data warehouse. Custom sources connect via the Loktak REST API and are mapped to the canonical finance schema automatically. No engineering sprint required.








Custom connector configuration and field-mapping examples are in the technical documentation.