QUESTIONS AND ANSWERS

What is Elyse?

Elyse is a controlled document management system built on Microsoft SQL Server. It is designed for organizations that need to manage controlled documents such as procedures, standards, SOPs, work instructions, quality plans, manuals and engineering drawings. It is equally capable of storing general documents that don't require formal document control.

Elyse uses a register-centric architecture where document identity, release control and metadata relationships are enforced at the database schema level. File storage is immutable and transactionally consistent with relational data. Authentication and access control are enforced at the database layer using Windows Integrated Security, not at the application layer.

Licensing is a single perpetual fee of US$3,500 for unlimited users with no subscriptions or ongoing charges. Single-user and non-production environments are free.

What makes Elyse different from other document management systems?

Most document management systems are built around file sharing, collaboration or workflow management. The requirements of controlled documents — unique identification, release control, immutable history, metadata integrity — are typically constructed as an additional layer on top of a general-purpose architecture. This creates a gap between how the system works internally and how controlled documents actually work in the real world.

Elyse was designed from the ground up specifically for controlled documents. The database schema directly mirrors the real-world structure of controlled documents: a single register of document IDs with schema-enforced uniqueness, releases as distinct objects linked to document IDs, and files as children of releases. This means the fundamental rules of controlled document management are enforced by the database itself, not by application code or custom scripts.

The practical consequence is that many of the common pathologies of document management systems — duplicate identifiers, broken cross-references, identity confusion after migration, inability to perform a simple document-ID-equals search — are structurally impossible in Elyse. See Fundamentals of Controlled Document Management for a detailed discussion of these architectural differences.

What is a register-centric architecture?

A register-centric architecture means that the primary entity in the system is the document register — a single table of user-facing document identifiers with a database-level unique constraint. The document ID that users see and search for is the authoritative identity, not a subordinate metadata field attached to a file or an abstraction managed by the application.

This is in contrast to object-abstracted architectures where the primary identity is an internal system identifier (such as a GUID) and the user-facing document ID is treated as a secondary attribute. In register-centric systems, document identity is owned by the organization. In object-abstracted systems, document identity is owned by the software.

The register-centric approach ensures that a search for a document ID is a deterministic lookup against a unique register, not a fuzzy search across metadata fields. One ID, one search, one result.

Can Elyse handle general documents as well as controlled documents?

Yes. While Elyse is purpose-built for controlled documents, it is equally capable of storing general documents that don't require formal document control — such as reference material, correspondence, vendor literature or supporting records. These can coexist alongside controlled documents within the same system, benefiting from the same secure storage, searchability and access controls without needing to be subjected to the constraints applied to controlled documents.

How does Elyse handle version and revision control?

Elyse makes a clear distinction between a document, a release and a file. A release is an object which is distinct from a file and distinct from a document. It forms the bridge between documents and files.

Each release of a document is stored as a complete separate file, or set of files, and cannot be altered once issued. The published release can be reverted or rolled back by changing the release state.

The system of release identification is unrelated to the file format or file editing system. Release identifiers can be maintained to a consistent format and sequence across changes in file formats. The identifiers from legacy systems can be migrated unchanged. The CDMS does not constrain how release identifiers are formatted — they can be numbers, letters, dates or any combination.

Elyse also makes a distinction between approval, release and, optionally, when a release becomes or ceases to be effective.

How does Elyse handle authentication?

Elyse relies on Windows Integrated Security. Once a user has logged into a Windows account the Elyse SQL database is the sole arbiter of user authentication. The database maintains a zero trust relationship with the application layer. It uses ORIGINAL_LOGIN() to resolve and authenticate users against SID-based ACLs stored within the database. No token passing occurs. The application layer is only responsible for ensuring that the configuration preserves the integrity of ORIGINAL_LOGIN() responses.

User authentication is verified within the database every time a call is made that requires privileges. No security state is stored beyond the scope of a single call or single stored procedure.

What is the database-layer trust boundary?

The database is the primary trust boundary. All application access to data is enforced through fully parameterized stored procedures. The application requires zero privileges and only needs credentials for one or more application roles. Access to data is further restricted by ACLs checked against ORIGINAL_LOGIN() in each stored procedure that performs a privileged task.

All stored procedures contain no data definition language (DDL), no data control language (DCL), and no dynamic SQL capable of structural SQL injection. Access by stored procedures to underlying tables is via internal ownership chaining.

This means that even if the application layer is compromised, the database enforces its own security independently. The application layer can be segmented by configuring an application with credentials for a single application role, preventing it from executing stored procedures for other roles.

Can files be modified after publication?

No. All file storage is immutable. Once a file has been stored it cannot be edited. There is no concept of editing a file in place. Each release of a document is stored as a complete separate file or set of files. Files can only be deleted if particular DBA-level settings have been configured to permit file deletion. Once a document release has been set to an Authoritative or Historical state the set of files forming the membership of the release cannot be altered, again unless DBA-level settings have been configured to permit it.

How does audit logging work?

Built-in audit logging is provided for essential requirements such as modification of key metadata, file access, file deletion, privilege granting and revoking, workflow actions, and authorization attempt failures. Additional fine-grained auditing can be enabled by configuring Microsoft SQL Server Audit. Audit logging is atomic with the associated transaction. That is, the transaction cannot be completed unless the audit log also completes. Audit logs are immutable at all user role levels.

Can data at rest be encrypted?

Yes. Data at rest can be encrypted using Transparent Data Encryption (TDE) on supported Microsoft SQL Server editions. The FILESTREAM data can be encrypted using BitLocker.

Why does Elyse store files inside the database rather than in external storage?

The principle of ensuring that data remains consistent with the associated files is that of transactional integrity. Specifically, the transactions must be ACID-compliant. Otherwise the data can readily become corrupted. A relational database engine can guarantee transactional integrity, but only if the binary content of the file is under the full control of the database.

The approaches to storing files and associated metadata have evolved over time. The most recent development is cloud object storage. Cloud object storage offers extreme levels of scalability and other benefits, but has the drawback of compromising transactional integrity compared with frameworks where the file binary content is under the full control of the database. For some solution needs transactional integrity is less important. For a CDMS solution however the integrity of the data is critical. The prospect of users being presented with an obsolete document, or a sensitive and restricted document, due to data corruption caused by a failed transaction for example, would not be acceptable. Transactional integrity with cloud object storage can be managed by the application layer, but it inherently can never be as robust as where it is entirely managed within the relational database engine.

Elyse uses Microsoft SQL Server FILESTREAM, which stores file binary data on the file system but under the full transactional control of the database engine. This provides the performance benefits of file system storage with the transactional integrity guarantees of the database. Relational data and file data are stored and backed up within the same SQL Server–managed system. The database provides transactional consistency between relational data and file data, including during backup and restore, preventing orphaned data under normal SQL Server–managed operations.

Storage of file data has evolved over time. The binary content of files can be stored directly within a binary column within a database table (referred to as a Binary Large Object – BLOB). This approach tends to create scalability and maintainability issues however. Conversely, when file binary data is stored external to the database the database loses its inherent ability to guarantee transactional integrity. If the data is stored external to the database then the application layer must assume responsibility for managing transactional integrity. In 2007/8 Oracle and Microsoft introduced solutions to this problem with SecureFiles and FILESTREAM respectively.

However SecureFiles and FILESTREAM still present limitations in the context of extremely large and distributed architectures. Hence for very large scale and distributed requirements (e.g. petabyte scale volumes), cloud object storage (such as Azure Blob Storage, Amazon S3 and Google Cloud Storage) have been developed as a more cost-effective solution. These solutions allow multi-tenanted, centrally managed storage for any scale, small or large.

The drawback of cloud object storage is that transactional integrity with an associated relational database must be mediated by an application layer. For solutions where transactional integrity is important, cloud object storage is inherently less robust in its integrity guarantees than options where the file binary data is under the full control of the relational database engine. Cloud object storage also introduces a security framework which is separate from and in addition to that of the relational database. All these challenges are manageable, but the solutions entail compromises. A security and integrity framework comprising an encapsulated single security model with transactional integrity fully assured, all within a single system without involvement of an application layer, is not possible with cloud object storage. However this framework is possible with a solution based on a relational database which retains full control of the file binary data content.

What are the system requirements?

Elyse requires Microsoft SQL Server Express 2022 or higher. For multi-user network deployment it requires standard Windows and SQL Server administration skills, including Kerberos Constrained Delegation. It can also be installed locally on a single machine for a single user, with all components – SQL Server, backend and web frontend – self-contained, fully-featured and ready to run.

Detailed deployment instructions are available on the Deployment Guide page.

Can Elyse be deployed in an air-gapped environment?

Yes. The licensing system does not need to call home. Elyse can be immediately deployed to an air-gapped environment.

Can Elyse be deployed as cloud-only?

No. Elyse requires on-premises Windows and SQL Server infrastructure. This is a deliberate architectural choice. The security model relies on Windows Integrated Security and the file storage integrity model relies on SQL Server FILESTREAM — both of which require direct control of the underlying infrastructure. These are the mechanisms that enable the security and integrity guarantees the system provides. See Fundamentals of Controlled Document Management for a discussion of the trade-offs involved.

Can Elyse run on a single machine?

Yes. Elyse can be installed locally on a single machine for a single user, with all components – SQL Server, backend and web frontend – self-contained, fully-featured and ready to run. A single-user environment is free with full access to product features.

Can Elyse run on Mac, Linux, or other database platforms?

No. Elyse specifically leverages Windows Integrated Security for its authentication and access control model, and Microsoft SQL Server FILESTREAM for its file storage integrity model. These are not portable abstractions — they are foundational architectural choices that the system's security and integrity guarantees depend on.

What skills are needed to deploy Elyse?

For multi-user network deployment, standard Windows and SQL Server administration skills are required, including Active Directory and Kerberos Constrained Delegation configuration. Minimal specialized knowledge of Elyse itself is needed. For single-machine deployment, no specialized skills are required beyond basic Windows administration.

How much does Elyse cost?

US$3,500 (plus applicable taxes) for a perpetual per-database-instance license. This covers unlimited users with no restrictions on data volume. There are no subscriptions, per-seat costs or ongoing charges. See Purchase a License for details.

Is there a per-user fee?

No. The license covers unlimited users.

Is there a subscription?

No. The license is a single perpetual payment. There are no recurring fees.

Can I evaluate Elyse before purchasing?

Yes. Elyse can be downloaded and used without restriction in a single-user environment or a non-production multi-user environment, with full access to all product features. A live interactive demo is also available with no registration required. See Downloads.

What does the license include?

The license covers the Elyse SQL database for production multi-user use on a per-database-instance basis. See the End User License Agreement for full terms. The application layer code is released separately under the Apache License 2.0.

Does the license fee include support?

No. Elyse is designed for self-service use. Users can rely on the included documentation for installation, configuration and operation. Multi-user network deployments require Windows KCD/AD and SQL Server administration skills. For additional support beyond the documentation, a separate service provider will need to be engaged. See Authorized Service Providers.

What is the Right to Maintain clause?

The EULA includes a Right to Maintain clause, ensuring that you will be able to keep your asset operational no matter what. This means that even if Silkwood Software ceases to operate, the licensee retains the right to maintain and modify the database to keep it functional.

Can I build my own application on top of Elyse?

Yes. The Elyse database exposes approximately 1000 application-facing stored procedures that serve as the database API. Any third party may develop an application that interfaces with the Elyse database.

What is the database API?

The database API consists of approximately 1000 stored procedures organized into role-based schemas. These stored procedures are the sole interface for application-layer access to data. The API is fully documented in the Database Technical Documentation. The complete source code for all stored procedures, tables, schemas and application roles is publicly available by downloading and examining the database.

Is the application code open source?

The application layer code is released under the Apache License 2.0, which permits use, modification and distribution including for commercial purposes. The Elyse SQL database itself is licensed under a separate EULA.

Can Elyse integrate with other systems?

Yes. The transparent and open architecture of Elyse — fully documented stored procedures, no obfuscated code, Apache-licensed application layer — ensures that it can be readily integrated into complementary systems. Any system that can call SQL Server stored procedures or interface with the application layer API can integrate with Elyse.

Can I migrate existing documents into Elyse?

Yes. The database API supports bulk creation of document IDs, releases and file associations. Document identities can be established and finalized in the system before loading the associated files.

Will my existing document IDs and revision numbers be preserved?

Yes. Elyse does not impose constraints on the format of document IDs or release identifiers. Existing document IDs can be registered exactly as they appear on the source documents. Release identifiers — whether numbers, letters, dates or any combination — can be migrated unchanged. The release identifier series does not need to restart or change format.

Do I need to modify existing documents to import them?

No. Elyse does not require documents to be changed to cater for constraints of the system. The document IDs and release identifiers printed on existing documents are registered as-is. Solutions which require documents to be changed, not to fix errors on the documents but to cater for constraints of the system, are symptomatic of a system that was not designed to mirror the real world. Changes would only be required if there are duplicate document IDs or duplicate releases for the same document.