Schedule of capabilities
What we do
Four things, and one segment we are honest about not having delivered yet.
- Sheet
- A-02
- Title
- Capabilities
- Issued for
- Information
- Drawn by
- Snilld
Most of the information a business runs on arrives as a file somebody else made up the format for. A twelve-sheet drawing set. A statement exported from a bank. A specification written in a word processor in 2014. We extract structure from these where the structure is implicit — layout where the document has one, vision where it is drawn or photographed, and deterministic rules where the format genuinely never changes.
- Multi-sheet drawing and CAD extraction, producing hierarchical quantities
- Statement, invoice and form parsing, including password-protected files
- Scanned and photographed documents, where the source is a phone camera
- Output in the spreadsheet or report format your process already expects
A model let loose on a general corpus will answer confidently about your products and get it wrong. The useful configuration is the restricted one: the model may only answer from a defined body of your documents, and when the answer is not there it says so. That refusal is the whole point. It reduces invention substantially. It does not remove the possibility, and we build on that assumption rather than against it.
- Retrieval restricted to a defined, versioned corpus
- Explicit refusal when a question falls outside the ingested material
- Answers that cite the passage they came from, so a person can check
- Hybrid keyword and semantic search where recall matters more than neatness
Serving several customers, brands or branches from one system is an engineering discipline, not a configuration screen. Get it wrong and you end up maintaining a fork per customer. We build tenancy at the data layer so the boundary holds even when the application has a bug.
- Row-level isolation in the database, not only in application code
- Vanity hosts and per-tenant branding from a single deployment
- Roles from platform owner to end user, checked server-side on every request
- Per-tenant configuration, content, legal consents and audit trails
We read from the systems you own and write back into them. That is a deliberate constraint rather than a limitation: an ERP you cannot expose, a factory that cannot take new hardware and a team that will not accept a new login are the normal conditions, and a design that requires any of them to change tends to stall in year one.
- File in, file out where an API is not available or not permitted
- Write-back into ERP and CRM records rather than a parallel database
- Installable web apps that work on the phones and laptops already on site
- Offline-tolerant behaviour where site connectivity is unreliable
We are actively interested in local government and other regulated work, where the requirements are usually more formal rather than less: accessibility as an obligation rather than a preference, data residency stated precisely, and an audit trail that a reviewer can follow. These are conditions we design for by default. We have no delivered public-sector engagement yet, and we would rather say so than imply one.
- Accessibility built to WCAG 2.1 AA, verified in continuous integration
- India-region data residency, stated in writing
- Append-only audit trails and versioned consent records
- Open-format export, so nothing is locked in a vendor database
Key plan
How it connects to what you run
Pick a system to see what reading it and writing back to it means in practice.
ERP. We read master data, stock and pricing through whatever interface it already exposes — an API, a database view, a nightly export, or a report someone currently opens by hand. Results are written back as records your ERP already understands, so your finance team reconciles in the system they audit in. Nothing is re-platformed and no module is replaced.
CRM. Contacts, opportunities and correspondence history stay in the CRM and stay the source of truth. We read them for context and write back notes, statuses and generated documents against the existing record, so your team never has a second place to check and no history is orphaned in a new tool.
Document stores. Most of the knowledge is here rather than in any database — drawing sets on a shared drive, specifications inside email threads, addenda published to a tender portal. We read the files in place, keep a pointer back to the exact page a figure came from, and never move or reorganise your folders.
Field devices. The last step is usually a person on a site, a poolside or a shop floor with one hand free and a bad signal. That runs in the browser on the phone they already own, works when the connection drops, and syncs when it returns. No fleet of tablets to buy and no app for anyone to install.
What your IT reviewer will ask
- Access
- Role-based, down to the record.
- Audit
- Append-only. Corrections add, never overwrite.
- Residency
- India region. Stated, not implied.
- Exit
- Open-format export, on demand.
Flow diagram
Where the gate sits
Five stages from intake to output. The confidence gate is marked, because it is the point: anything the system is unsure about stops there for a person.
Intake
A photo taken on site, a twelve-sheet drawing set, a password-protected statement, a paper form scanned on a phone. It arrives in whatever shape it already has.
PDFDWG / DXFXLSXCamera
Reading
Layout-aware extraction where the document has a structure, vision where it is a photograph or a drawing, and plain deterministic rules where the format never changes. The cheapest method that works is the one we use.
Layout parsingVisionRule engine
The confidence gate
The stage the whole architecture exists for. Anything the system is unsure about is marked, queued and left blank rather than filled with a plausible value. A person clears the queue, and their correction feeds the next run. A confident wrong number is worse than a blank one.
Confidence scoringReview queueCorrection memory
Your record
One place the answer lives, scoped so one entity can never read another, with an append-only trail of who changed what and when.
PostgresRow-level securityAudit trail
Back where you work
The answer goes back out to the system you already use — an ERP write-back, a CRM record, a spreadsheet export for whoever still wants a spreadsheet, or a phone in someone’s pocket.
ERP APICRMExcel exportMobile
General notes
How a project runs
Five principles. Each one concedes something real, which is the point of writing them down.
The model drafts. Your people approve.
Anything that leaves the building with your name on it — a price, a schedule, a compliance return — passes a named person first. The system’s job is that there is nothing left to type.
It has to survive contact with your estate.
A demo that works on clean data is not evidence. We test against your exceptions, your part-numbering, and the three customers who are always billed differently.
Adoption is the project.
Systems in this bracket fail on adoption, not on features. We build for the person who did not ask for this, on the device they already carry, and we write the guide their supervisor can teach from.
Confidence is visible.
Every output carries how sure the system is. Low-confidence items are queued for review rather than quietly filled in, and each correction improves the next run.
Production, or it does not count.
A service level, monitoring, a rollback path and a runbook. We would rather hand over something running than something rendered.
Section A–A
The stack, and why
We pick what fits the problem. The pattern that recurs: TypeScript on the surface, Python where documents and models are hard, Postgres in the middle.
Surface
TypeScript and React. Installable web apps, so there is nothing to distribute and nothing to install.
Services
Python where documents, drawings and models are hard. TypeScript where the surface is. Postgres in the middle.
Models
We choose per task and stay portable: a fast tier for extraction, a reasoning tier for judgement, deterministic code wherever a model is not actually needed. The orchestration, the memory and the integrations are the part that is ours.
Operations
Containers on Oracle Cloud in the Hyderabad region, health checks, structured logs, daily backups, and automated tests on every push.
Start with a prototype
Two to four weeks working from your own files, and at the end you hold something real. It is the cheapest way to find out whether any of this applies to you.
Start with a prototype