Medical AI,
built as a technology system
rather than one model

Where did the evidence come from?

A large collection of papers and guidelines is not automatically trustworthy evidence. Clinicians need to see where material came from, when it was observed, and what changed later.

AlphaEvidence keeps identity, provenance, usage context, and change history connected. It is not a database of stored answers; it is a foundation that lets people return to the evidence behind a judgment.

From source material to a reviewable judgment

When verifiable material enters the system, AlphaEvidence aligns its source and identity and connects later change and quality signals. AlphaDoc Engine receives evidence context with this lineage intact.

AlphaEvidence Foundation is connected to evidence paths in Alphadoc. Public counts describe the scale of literature records and guidelines; they are separate from any count of records that have completed clinical validation.

Designing what happens after the question

Evidence discovery, document work, translation, and record preparation need different inputs and review. AlphaDoc Engine identifies what the user is trying to do before it considers model execution.

It combines the evidence, document context, tools, and output form appropriate to that purpose. AlphaDoc Engine is not Viore's own large language model; it is the execution layer connecting Viore technologies to medical work. Viore's medical-specialized model (07) will also run on this execution layer and replace external models.

How purpose leads to the next action

After identifying the task, the Engine brings in the required AlphaEvidence context and available document or image artifacts. External execution that needs protection uses an AlphaLayer-covered path, and the result returns to user review and the next task.

This execution structure operates across several Alphadoc features. The scope and method of evidence-quality evaluation vary by feature.

From a document read once to knowledge reused

PDF, DOCX, HWP, and CSV files express structure differently. Extracting text alone can lose tables, paragraphs, source locations, and processing history.

AlphaDocument turns supported documents into Document Artifacts that keep recoverable structure and provenance together. Results can be checked again under the same input and processing basis, without trapping document knowledge inside one screen.

How a document becomes an artifact

AlphaDocument reads a supported document, organizes the structure and source locations it can preserve, and binds them to processing and integrity context. Alphadoc features that need document context can reuse the resulting artifact.

The core engine and product connection paths are implemented, while the scope of use continues to expand. What can be preserved varies by format, so the technology does not reproduce every table, image, or page layout exactly.

Set the input straight before interpretation

Format, orientation, dimensions, and coordinate conventions can make the same image appear different downstream. Separating source and transformed images also makes it easy to lose where a change occurred.

AlphaImage organizes supported static images into consistent representations and coordinates while keeping source and existing-annotation lineage inside an Image Artifact.

Bringing different images onto one reference

After checking that an input is supported, AlphaImage produces a safe shared representation and keeps coordinate transformations and existing annotation sources connected. Downstream features can reuse this common foundation.

Implementation and bounded synthetic-input runtime verification are complete, while activation in Alphadoc user paths remains under review. AlphaImage does not interpret or diagnose images, and patient-information readiness or legal suitability has not been established.

Resetting the boundary between LLM autonomy and security

Masking a few strings does not govern medical AI execution. The system must identify which task is using external AI under which conditions and stop requests that do not meet them before they leave the boundary.

AlphaLayer checks registered purpose and request conditions between AlphaDoc Engine and external AI execution. It applies policy to supported data types and text scopes and passes only the execution context that the covered path needs.

Only selected execution crosses the boundary

Selected protected text passes through a registered policy boundary for external execution. The returning result is checked against the request context before Alphadoc receives it, and only records needed to operate the covered path are retained.

Selected text capabilities in Alphadoc are runtime-verified through AlphaLayer. The protection scope does not automatically extend to every feature, identifier type, image, or source file, and remains distinct from patient-information readiness or legal suitability.

Separating conversation content from delivery data

Transport encryption alone can still leave stored content readable to a server. On supported one-to-one paths, AlphaSeal encrypts message bodies in participant browsers and leaves ciphertext in the ordinary storage path.

Delivery metadata such as sender, recipient, time, and read state remains separate. A participant can also decrypt and submit a reported message. AlphaSeal therefore does not mean that every piece of conversation information is invisible.

Sealed in one browser, opened in the other

Supported new messages are encrypted with conversation and sender-order context, then verified and decrypted in the recipient browser. Key protection and device-change paths depend on the supported environment and recovery setup.

The current scope is supported one-to-one messaging. Group conversations, perfect forward secrecy, protection after a participant browser is compromised, and suitability for transmitting patient information are outside that scope.

Why Viore builds its own model

Many medical institutions cannot send patient information or internal documents to commercial AI in external clouds. Serving these institutions requires a model that runs inside the institution without a frontier API. That is the first reason Viore builds its own model. The second is efficiency. A model that keeps the quality of medical answers while running on less compute with shorter response times is what makes operation affordable for an institution. The third is verification. Clinicians and institutions can trust a model only when we can state what it learned from which data and how it was evaluated.

How Viore's model is built

Our approach trains and optimizes medical knowledge on top of a proven open base model. Rather than training a foundation model from scratch, we focus on drawing the performance medical work requires out of a smaller model. Medical performance is evaluated against AlphaEvidence's evidence framework, under the same conditions as frontier and large models. Because AlphaDoc Engine was designed from the start not to depend on any single model, Viore's model takes the same place as external models: in institutional environments it replaces them, and in cloud environments it is selected according to institutional policy. Beyond that, we intend to extend it into institution-specific models within the scope each institution permits and with lawful authority.

From personal AI to institutional AI

Clinicians already use AI for work through personal accounts. But for an institution to adopt it as a work tool, medical-specific features alone are not enough. Data protection, access rights, operating rules, and audit records have to come together. Viore addresses this in two strands: on-premise Alphadoc, installed on an institution's internal servers or in a closed network, and an institution-level security framework that governs access rights and sensitive-data handling according to institutional policy. In on-premise environments, the medical-specialized model from 07 will run on internal servers and replace calls to external models.

Extending the AlphaLayer boundary to the institution

Today, AlphaLayer binds external AI execution to a registered policy boundary for selected text paths (05). The institution-level security framework is a design that widens this boundary: authenticating and checking access rights on every request, detecting and substituting sensitive data with token mapping, validating inputs and attachments, calling only permitted models, checking responses for leakage and restoration rights, and then applying institution-specific audit records and retention policies. Requests that fail validation are blocked before they leave the boundary.