Drawing
our own linearity.

Decide where the data lives, first

Healthcare providers and healthcare companies point to security and a lack of in-house expertise as the barriers to adopting generative AI. If documents and records have to go to an external AI, the institution has to check and manage that path itself.

Alphadoc keeps the model that answers, and the materials it uses, inside the institution's environment. It's installed on a corporate network or in a separate cloud, and it doesn't use external AI to answer. Personal notes are private by default, and the institution decides how widely they can be shared.

Evidence moves in one direction

New guidelines and literature are organized in AlphaEvidence and sent to each institution's environment. Model and security updates take the same route. The institution's documents, questions, and answers don't travel back to Viore.

This architecture runs on the corporate network at our first institution. It defines where data stays and how it flows. It doesn't establish an institution's legal basis for processing personal data, or its legal suitability.

From personal AI to institutional AI

Clinicians already use AI at work through personal accounts. But for an institution to adopt it, features aren't enough. It also needs data protection, access rights, operating rules, and audit records. Viore is building for this in two ways: Alphadoc installed on a corporate network or in a separate cloud, and an institution-level security framework that controls access and sensitive-data handling by institutional policy. Corporate-network Alphadoc is installed at our first institution and runs on an open base model inside the institution's environment. Viore's medical AI model will replace it.

Extending AlphaLayer across the institution

Today, AlphaLayer governs external AI execution with registered policies in selected text features. The institution-level security framework extends that control across the whole institution. Every request is authenticated and checked for access rights. Sensitive data is detected and swapped for tokens. Inputs and attachments are validated, and only permitted models are called. Responses are checked for leaks and restoration rights before delivery, and each institution's audit and retention policies apply. As a rule, requests that fail a check are blocked.

Why we build our own model

Many institutions can't send patient data or internal documents to commercial AI in the cloud. They need a model that runs inside the institution, with no external API. That's the first reason. The second is cost: answers have to stay good while using less compute and coming back faster, or institutions can't afford to run them. The third is trust. Clinicians and institutions should be able to see what data the model learned from and how it was evaluated.

How we build it

We start from a proven open base model and train and optimize it on medical knowledge. Instead of building a foundation model from scratch, we focus on getting the performance medical work needs out of a smaller model. We evaluate it against AlphaEvidence, under the same conditions as large commercial models. Because AlphaDoc Engine was never tied to one model, ours takes the place of the open base model running in institutions today. On corporate networks and in separate clouds alike, answers come from models inside the institution's environment. No external models are called. Next, within what each institution allows and with lawful authority, we plan to extend it into institution-specific models.

Separating what you say from how it's delivered

If only the connection is encrypted, the server can still read what it stores. With AlphaSeal, the sender's browser encrypts the message body, so what lands in the server's regular storage is ciphertext.

Delivery details such as sender, recipient, time, and read status aren't encrypted and are stored separately. For a report, a participant can decrypt and submit the message. So AlphaSeal doesn't hide everything about a conversation.

Sealed in one browser, opened in the other

Each new message is encrypted together with its conversation and send order, then verified and decrypted in the recipient's browser. Keys are protected based on the supported environment and recovery setup, with a recovery path for switching devices.

Today this covers supported one-to-one messages. Group conversations, perfect forward secrecy, protection for an already compromised browser, and suitability for sending patient information are out of scope.

Drawing the line for external AI

Masking a few words doesn't control how external AI gets used. You have to know which feature uses external AI and under what conditions, and stop anything that isn't allowed before it leaves.

AlphaLayer sits between AlphaDoc Engine and external AI and checks each request against its registered purpose and conditions. It applies policy to supported data types and text, and sends only what execution needs.

Only approved requests go out

Text marked for protection reaches external AI only after passing the registered policy. Results are checked against the original request before Alphadoc receives them, and logs are kept only to the extent operations require.

It's runtime-verified in selected Alphadoc text features. It doesn't cover every feature, every identifier type, images, or original files, and it doesn't establish patient-information readiness or legal suitability.

Get the input right first

The same image can look like a different one downstream if its format, orientation, size, or coordinates differ. Keep the original and the converted copy apart, and it's hard to tell what changed and where.

AlphaImage brings supported static images to one format and coordinate system, and creates an Image Artifact that keeps the history of the original and its existing annotations.

One standard for every image

It checks that the input is allowed, converts it to a safe common format, and records coordinate changes and annotation sources in the artifact. Later features reuse that result.

It's built and has passed limited runtime checks with synthetic images. Whether to bring it to Alphadoc's user-facing features is still under review. AlphaImage does not read or diagnose images, and patient-information readiness and legal suitability have not been established.

From read once to reused

PDF, DOCX, HWP, and CSV all store structure differently. Pull out only the text, and you lose tables, paragraph breaks, source locations, and processing history.

AlphaDocument turns supported documents into Document Artifacts that keep structure and source together. Same document, same rules, same result, so you can always check it again. The converted content then works across Alphadoc.

How a document becomes an artifact

It reads the document, maps the structure and source locations it can keep, and attaches the processing rules and integrity data. Any Alphadoc feature that needs the document can reuse the artifact.

The core engine and product connections are built, and coverage is growing. What can be preserved varies by format, so not every table, image, or page layout is reproduced exactly.

Designing what comes after the question

Finding evidence, working with documents, and organizing records each need different inputs and different checks. So before choosing a model, AlphaDoc Engine works out what you're actually trying to do.

Then it picks the evidence, documents, tools, and answer format that fit. AlphaDoc Engine isn't Viore's own large language model. It's the execution layer that ties Viore's technologies to medical work. Viore's medical AI model, now in development, will take the place of the model used here today.

From purpose to the next step

Once the task is clear, the engine pulls in AlphaEvidence and any usable documents or images. Requests that need protection on their way to external AI go through AlphaLayer, and results come back for your review before the next step.

This structure runs across Alphadoc features. How evidence quality is evaluated depends on the feature.

Where did the evidence come from?

Collecting more papers and guidelines doesn't make them trustworthy. Clinicians need to know where something came from, when it was checked, and what has changed since.

AlphaEvidence stores identity, source, terms of use, and change history for every paper and guideline. It doesn't store answers. It lets you trace an answer back to the evidence behind it.

From source to evidence

When new material arrives, AlphaEvidence matches its source and identity, then links earlier versions and quality signals. AlphaDoc Engine answers with that history attached.

AlphaEvidence is connected to how Alphadoc finds evidence. The public counts below show how many papers and guidelines we hold. They are not counts of clinically validated records.