Not a badge page. This answers what a document, a case and a decision touch, what a model sees and what it never decides, where your files live, and what is not yet built - stated plainly, because a security document that only says what is finished is worse than none.
Valinexis reads documents you send it, extracts named values, and checks those values against rules you configure. It produces findings, a report, and an audit trail. It does not transmit your documents to any party other than the model provider below, and only under the masking described there.
| Kind | Where | Why |
|---|---|---|
| The document files themselves | Blob storage | Re-reading, evidence, the report |
| Values extracted from them | Case database | What the rules are evaluated against |
| Findings and outcomes | Case database | The result, and its audit trail |
| Decisions a person made | Case database, append-only | Who accepted what, and why |
| Messages sent to a sender | Case database | What somebody was told, and when |
| Operational logs | Platform logs | Diagnosis |
This is the question every security review asks first, so it is answered first, and it is the architectural rule everything else on this page rests on.
No model call sits anywhere in the rule decision path.
Extraction is assisted by a model; evaluation is not. A rule that compares an invoice total against an approved estimate does arithmetic in code, against values already extracted, with a deterministic result. The same case validated twice produces the same findings, and every finding traces to the rule that produced it - "the model was having a bad day" is not a category of failure this product has.Document content is sent to a model to extract field values. Before it goes, recognisable personal data is replaced with opaque tokens, and restored after the response comes back. Which identifiers get masked is a per-tenant choice, not a fixed list - made on a screen in the console, not a code change or a conversation with us.
17 identifiers across nine markets. Turn on the ones that appear in the documents you actually send us.
Eight broadly-applicable identifiers are on from day one - a tenant who never opens the screen is not left unprotected.
Every pattern ships tested. You select from it; you do not author your own - a deliberate restriction, and it protects you. See below.
Paste a sample on the same screen and see exactly what a model would receive, before anything is saved.
| Identifier | Market / type | Default |
|---|---|---|
| Email addresses | Universal | On |
| Payment card numbers | Universal | On |
| PAN & Aadhaar | India | On |
| SSN | United States | On |
| National Insurance number | United Kingdom | On |
Why a catalogue, and not a box to type an expression into.
Every pattern ships tested - a customer ticks, they never author. That is because the failure people expect is a leak, and the failure that actually bites is the opposite: a pattern that matches too much hides the invoice total, the model cannot return a value it can no longer see, and the rule reading it reports that it could not be compared. Nothing errors, and the finding blames a document that arrived perfectly readable. Identifiers whose shape is loose enough to do that ship switched off, with a note saying what else they will catch. If you need an identifier the catalogue does not carry, that is a small addition on our side, not a limitation of the design.Structured data need not touch a model at all.
Where a value already lives in a system of record, a data contract template reads it by declared path - no model call, no confidence score, no redaction question to answer. See two kinds of document on the Platform page.Extraction uses Azure Document Intelligence and Azure OpenAI, on endpoints configured per deployment. Azure OpenAI does not train on submitted content and does not retain prompts for provider use.
Storage is bound per tenant and read fresh on every operation. Three configurations are supported, and the choice is yours.
| Configuration | What it means |
|---|---|
| Our storage, your own container | The default. Clean offboarding, per-tenant retention, and an access signature that can be scoped to you alone. |
| Your storage account | Every read, write, delete and download is served from storage you own, under a key you control and can revoke. If that key is unavailable, uploads fail loudly rather than quietly falling back to our account. |
| Your region | Recorded and visible on screen. Actual placement follows the storage account configured - the region setting is never used to silently route anything. |
Storage account keys, mailbox credentials, webhook signing secrets, SFTP keys - every credential the product holds is referenced by name and resolved against a vault at the point of use.
A database backup, a read replica, or a compromised reporting connection returns the names of secrets and nothing that opens anything.
A misconfigured secret name causes a refusal, not a fallback. A webhook that cannot be signed is not sent unsigned.
Secrets are never written to logs, never returned to an API caller, and never placed on a visible record.
Isolation is not a single wall - it is enforced at three separate layers, so one weak point does not become the whole boundary.
Every internal call carries an HMAC-signed tenant assertion. The API refuses to start without a signing key configured - an unconfigured key is treated as a hard failure, not a soft one.
The submission endpoint authenticates with a per-source API key, compared in constant time. An unknown key, a paused source and a wrong key all return the same response - the endpoint cannot be used to enumerate what exists.
Every table carries a tenant identifier and every stored procedure filters on it. Tenant scoping is enforced at the data layer, not only in application code.
The full shape of each route is on the Developers page. This is the authentication behind each one.
| Route | Direction | Authentication |
|---|---|---|
| Watched folder / file share | In | Filesystem or share permissions you control |
| Mailbox | In | App registration with application permissions, scoped by an Application Access Policy, plus a sender allow-list |
| Platform API | In | Per-source API key |
| Webhook | Out | HMAC-SHA256 signature over the exact bytes sent |
| Report files | Out | Written beside your documents, in storage scoped to your tenant |
The parts of the record that matter to an audit are append-only by construction, not by convention.
A decision cannot be revised after the fact. A reversal is a new entry, never an edit. Accepting a case that carries blocking findings requires a stated reason, enforced in the database rather than in a screen.
A communication marked Sent means a message was actually attempted and accepted for delivery. If it did not go, the record says Failed and carries the reason - it cannot claim a sender was told something they were not.
What was processed, what failed, and why - queryable, not something you find by opening a folder on a server.
Editing a rule does not erase what it was. A finding recorded years ago still resolves to the rule that raised it, in the wording it had at the time.
The platform submission endpoint is the only route a party outside your network reaches directly.
Partitioned per API key, so one caller looping on a rejected key cannot spend another tenant's allowance or saturate extraction for the deployment.
Reports whether the database answers, and returns only the exception type - never the message, which would turn a health probe into reconnaissance.
Recognised by content hash. The same document sent twice is not attached to a case twice, and a re-sent bundle does not double a line-item table.
A security document that only lists what is finished is worse than no document, because it gets relied on. These are real gaps, not hedging.
We record what the system did. We do not yet record which person opened which case.
There is no scheduled deletion and no automated flow for a subject erasure request. Removal today is a manual operation.
Any holder of the internal signing key may act for any tenant - correct for our own services, not yet offered for an agent running on your own infrastructure.
No independent penetration test has been commissioned. SOC 2 and ISO 27001 are not currently held. Controls are designed for these frameworks; certification is not claimed.
The catalogue, the per-tenant selection and the preview are recently released. The service beneath is tested; if you configure masking, use the preview and check a real sample before relying on it.
Repointing a tenant's storage takes effect across services within thirty minutes, not instantly. Documents ingested inside that window land in the previous account.
A fuller written Security Overview goes deeper into each control and states current build status against SOC 2 and ISO 27001 control families - written for a reviewer, not a buyer.
+91 7702820516
