Engineering at Permadyn
Try a document review workflow, inspect a published dataset, or review the checks behind a release. These examples show how we build and verify software, with the sources and limitations beside the result.
Interactive example · Fictional documents
Follow one supplier invoice from source documents to a reviewed draft. Load a missing reference or a repeated invoice, inspect the checks, and resolve the exception yourself.
Try the document review exampleFixed rules extract the labeled sample fields. This browser example demonstrates workflow controls, not AI accuracy or a customer outcome. It makes no external changes.
Reference build · Fictional data · v1.0.0
An order can look valid on its own and still point to a missing account or contain the wrong total. This reference connects accounts, orders, line items, and payments, then checks the rules between them.
Download the reference (JSON)Generated from written rules with a fixed random seed, so it can be reproduced exactly. The results below show that this dataset’s software checks work; they do not measure a customer outcome or model performance.
Included in the release
The six broken cases introduce a duplicate order ID, a missing account, a wrong subtotal, a wrong total, an incorrect payment, and an early payment date. Each one has an expected failed check in the release.
SHA-256 identifies the exact downloadable file:
696c2c753ff9bff78f04b4596203ed9d6fc16f7f74177e000ce8bcc1092b253aMore to inspect
12,000 fictional requests with expected routing outputs, review flags, a schema, and file checksums. The release documents how related examples are assigned to training and evaluation splits.
A sample of our delivery format. Because the same templates appear in the training and evaluation splits, it cannot show how well a model would handle new cases.
Inspect the datasetCompare GPU memory limits, software compatibility, equipment budgets, and DGX Spark cluster layouts. Each recommendation explains its tradeoffs and links to manufacturer information.
Sizing guidance only. Actual performance has to be measured on the proposed system.
Review the hardware choicesA blank plan for recording the exact system, model, task-quality criteria, latency, concurrency, and recovery checks before purchasing or accepting a deployment.
A template to complete during a project, not a finished benchmark report.
Download the acceptance planBefore production
We agree on the required evidence when we scope the project. The review covers the application, its integrations, and the people responsible for operating it.
We run representative tasks against expected results, record the errors, and make an acceptance decision. For AI output, we also check for omissions and unsupported answers.
We document which data each role can read and which actions it can take, then test that denied access stays denied. External model calls and data movement are documented too.
We test failed integrations, timeouts, duplicate requests, and the recovery steps. The release plan names who can stop or roll back the system.
The handoff lists accounts, source-code rights, configuration, recurring costs, operating instructions, and support responsibilities. Coverage is agreed before release.
Bring a document to process, a system to connect, or a workflow that takes too much manual work. We’ll identify the first useful build and how you will judge it.