Frequently Asked Questions

CIRMS helps teams run routine operational work, see the condition of their systems and prepare the information those systems produce for AI use. The name stands for Centralized Intelligent Resource Management System.

It brings automation and visibility together instead of leaving people to collect information and repeat the same checks manually. CIRMS GL3 handles operations, GL4 prepares knowledge, and GL5 is the planned intelligence extension.

Imagine a team looking after many servers. One server is running low on disk space.

GL3: a configured check collects the free-space value, compares it with a threshold and makes the result visible to the team. GL4: prepares that information with its source, structure and version so it can be used as part of a knowledge foundation. Planned GL5: could use that prepared knowledge to help a person investigate or ask questions.

CIRMS GL3 — Intelligent Automation & Data Acquisition: carries out defined operational tasks, monitors resources and collects data.

CIRMS GL4 — AI Data Readiness: turns selected operational data into structured, versioned and validated knowledge assets.

CIRMS GL5 — AI Intelligence: is planned development for AI-assisted analysis, conversational access and decision support using that foundation.

Think: do the work → prepare the knowledge → help people use it. The three labels describe different responsibilities, not three names for the same function.

GL means Global Layer. It identifies a responsibility within CIRMS: operations, knowledge preparation or planned intelligence.

A software version identifies a particular release or build. A GL label is not a release number, a hardware size or a claim that a later layer replaces the earlier one.

No. CIRMS works with the connected systems in the agreed deployment. Your databases and business applications remain the sources of operational information.

The aim is to reduce repetitive administration and make activity easier to inspect. People still define tasks, approve access, investigate exceptions and own operational decisions.

Preparing reliable information and answering questions about it are different jobs. A useful answer needs the right source, enough context and an understanding of which version is current.

GL4 addresses that preparation problem. The planned GL5 layer would use the resulting knowledge for assistance. Finishing GL4 does not automatically create a chatbot or make every answer correct.

CIRMS is relevant wherever teams need repeatable digital operations and clearer information: for example, IT services, industrial operations, finance, utilities or public-sector environments.

The starting point is the actual workload, not the size of the company. A smaller environment may begin with a limited scope; a larger one may need several coordinated deployments. Sector-specific needs and controls must be assessed rather than assumed.

No. Start with the short explanations and examples. Terms such as document, chunk and vector are explained below before you need to use them.

Reading a dashboard is different from configuring a deployment. Technical administrators are still needed for connectivity, permissions, source registration, workflow design and troubleshooting.

GL3 brings together reusable automation tasks, workflow execution, operational data collection, monitoring, health checks and reporting.

A configured task might inspect a service, collect database information or run an approved administrative operation. The dashboard then helps the team review the execution and any problem that needs attention. The available task set depends on the modules and resources included in the deployment.

HERCULES is a CIRMS operational execution unit. It works close to a managed environment and runs the configured work for that environment.

HERCULES performs GL3 automation and data acquisition and can also run the GL4 preparation pipeline. The name describes its CIRMS role; it does not mean that every HERCULES deployment has identical resources, modules or capacity.

ATLAS is the coordination and oversight component for a broader view across HERCULES environments. HERCULES performs the local work; ATLAS brings the environments together for coordination and visibility.

A single-environment design can start with one HERCULES. ATLAS is relevant when the deployment needs wider coordination. It is not another name for GL5, and its presence does not mean a chatbot is available.

An ATOM is a small, focused, reusable unit of execution. CIRMS also uses the term atomized bot for these building blocks. A module groups related capabilities. A workflow coordinates tasks into a useful sequence.

A job is a unit of work that can be executed. Scheduling decides when it runs. Orchestration coordinates the steps, their order and their dependencies.

For example, collecting data must happen before a report can use the new results. CIRMS records execution activity so the team can distinguish a completed run from one that failed or did not run.

It means collecting information from an authorised source so that it can be monitored, reported on or prepared further.

Examples include host configuration, service status, database details and storage usage. GL3 provides the operational collection foundation. Which databases, applications, files or services can be connected depends on the supported integration and access agreed for that deployment.

Monitoring shows recorded activity or measurements. A health check tests a condition against a rule.

Always consider the time of the measurement and the check configuration, not only its colour on a dashboard.

The CIRMS interface provides Automation, Healthcheck, Monitoring and AI Data views, alongside operational, database and business reporting. Database reports may be labelled RDBMS, short for relational database management system.

Depending on the view, you can inspect managed resources, task results, failed checks, stage duration and data-readiness counters. A dashboard is an overview; the execution or object-level detail explains why a particular result needs attention.

See the CIRMS interface →

No. Detecting a problem and changing a system are separate actions.

Corrective work must be explicitly configured, authorised and supported for the environment. Some conditions should trigger investigation or a notification rather than an automatic change. “Automation” should not be read as unlimited self-repair or permission to alter any system.

In a hub-and-spoke arrangement, connected resources communicate with a central operational unit. In a larger CIRMS hierarchy, several HERCULES units can sit beneath ATLAS coordination.

Some earlier material used “snowflake” to describe a branching arrangement. Here, the intended idea is a deployment hierarchy—not a promise of a Snowflake data-platform integration or a particular database schema.

Compare the deployment models →

GL4 turns selected operational data into structured, traceable knowledge assets. It checks the source, prepares the data, creates AI documents and versions, builds chunks and vector representations, and validates the preparation result.

The process is visible as stages 0–7. It is a preparation pipeline, not a chat application and not a guarantee that the original business information is true.

GL3 handles operational collection and execution. GL4 handles preparation for AI use. GL4 still has its own raw-data loading stage for registered inputs; this does not make it responsible for repairing infrastructure or administering every upstream system.

For example, GL3 can collect storage information into an operational dataset. GL4 can then register the eligible table and prepare that dataset as knowledge. A missing permission or unsupported source must be resolved at the appropriate source or operational layer.

Not automatically. The current preparation path described here is based on eligible, registered source tables. A source must meet the relevant schema, identity, access and extraction requirements.

The term “AI document” does not mean that GL4 accepts every uploaded Word or PDF file. Additional sources and formats need an explicitly supported integration and agreed deployment scope.

Registration tells GL4 which source object it is allowed to prepare and how to handle it. A technical administrator supplies the server, database, schema and table, together with the relevant identity and change-detection settings.

CIRMS validates the registration instead of treating every table as eligible. A registered object is an agreed input, not permission to copy every database or every file in the organisation.

Identity asks: “Which record is this?” Change detection asks: “What changed since the previous read?”

Keeping them separate helps CIRMS follow document history without confusing a changed record with an entirely new record.

SOURCE_KEY uses an eligible key from the source to recognise a record, such as a suitable primary key or unique key. KEYLESS uses a supported strategy where there is no usable source key. AUTO asks the registration process to resolve a supported choice.

KEYLESS does not mean “identity no longer matters.” Duplicate-looking rows and updates need different handling when the source has no stable key. AUTO is also not a bypass for validation.

These are ways to find source changes. The appropriate choice depends on the source and the configured CIRMS strategy.

Change Tracking

Identifies changed rows so their current values can be read. It is not a complete history of every intermediate value.

CDC — Change Data Capture

Captures insert, update and delete information for the configured database capture scope.

Rowversion

A database-generated change value for inserted or updated rows. It is not a clock time and does not, by itself, record deleted rows.

Watermark

A remembered progress marker, such as a suitable change value, used to select later records. Its reliability depends on the source rules.

Full snapshot

A read of the current in-scope dataset that can be compared with an earlier accepted state.

A setting is usable only if its prerequisites and capture scope are valid. No method should silently turn an unreadable source into apparent mass deletions.

Database background: Change Tracking, CDC and rowversion. These explain the database concepts, not universal CIRMS source support.

Metadata is information about the data. A schema describes its structure: column names, types, permitted empty values and keys.

GL4 checks structure so it does not prepare a changed source using an outdated assumption. A column rename and a changed value inside the same column are different kinds of change.

The refresh frequency is set by the deployment schedule and source strategy. A dashboard can show the latest recorded result without representing the source at this exact second.

Check the last successful scan, object status and stage timings when freshness matters. The source size, amount of change and processing capacity affect how quickly a run completes; there is no universal “instant” refresh promise.

A scan is one processing run for the selected registered sources. CIRMS numbers the first stage zero, so stages 0 through 7 are eight stages.

The order is source metadata → raw data → curation → AI documents → chunks → vector embeddings → semantic validation → readiness completion. A scan may cover more than one source object, with results recorded at both run and object level.

A run with no eligible work is different from a failed run or a run that prepared new knowledge.

Input: the registered source and its current definition. Work: inspect the structure, keys and relevant extraction assumptions before reading it into the preparation flow.

Result: a refreshed source definition and validation outcome. In the storage example, CIRMS checks that the expected server and free-space columns still exist and can be handled. A missing table or unsupported structure is not silently accepted as an empty dataset.

Input: an eligible source and a supported acquisition strategy. Work: load the source data needed for the run into the raw preparation area.

Result: captured input for the next stage. “Raw” means it has been acquired, not that it has already passed every preparation check. A snapshot reads the in-scope current state; an incremental strategy uses its supported change mechanism.

Input: raw data and the expected structure. Work: validate the physical schema and apply the configured preparation rules to produce a consistent curated dataset.

Result: structured data suitable for document generation. A storage value needs a consistent field and type; a structural mismatch must be surfaced. Curation is not permission to invent a missing measurement or rewrite the original source silently.

Input: the curated dataset. Work: build a document representation and associate it with the source record, its identity and version history.

Result: AI documents and the relevant current or historical versions. For example, a prepared record can describe APP-01 and its recorded storage value together. New content and unchanged content should not be counted as the same kind of event.

Input: an eligible document version. Work: produce manageable pieces of content using the configured chunking rules, keeping their connection to the document.

Result: chunks for the next stage, with new and reusable content distinguished. A short document may yield one piece; a longer one may yield several. The count depends on the content and configuration, not on a fixed one-row-to-one-chunk rule.

Input: eligible chunks and an active vectorization configuration. Work: apply the configured embedding process to create numerical representations.

Result: vectors associated with their chunks and configuration. A compatible setup must be available; an absent configuration is not a reason to invent vectors or skip the requirement. Creating a vector is also not the same as passing the later retrieval and readiness checks.

Input: the prepared assets, approved vector relationships and configured retrieval scope. Work: validate that the required retrieval paths use the correct eligible assets and produce structurally valid, repeatable results for the checks performed.

Result: a semantic-validation outcome used by the final readiness stage. The links among source, document, version, chunk and vector matter—not only whether some vector exists.

Input: the required preceding outcomes and approvals. Work: check the completion requirements and record the final preparation result for the relevant scope.

Result: a completed readiness outcome that can be inspected in the monitoring views. Completing Stage 5 or Stage 6 alone is not the same as completing the whole run. Failed or missing requirements must not be presented as successful readiness.

An AI document is the prepared representation of source information inside the CIRMS knowledge pipeline. Think of it as a labelled information card with content and links back to where it came from.

It does not have to be a PDF or Word file, and “AI document” does not mean a chatbot invented the text. Its purpose is to make selected source data usable in the later preparation stages.

A document is the continuing record; a version records its content at a particular preparation state.

History helps explain what changed. Historical versions are not automatically the versions eligible for current retrieval.

A chunk is a smaller piece of a document. A useful analogy is a paragraph taken from a longer report while retaining its label and source reference.

Smaller pieces let a retrieval process work with a relevant portion instead of an entire long document. In CIRMS, a chunk stays linked to its document version; it is not a disconnected piece of text.

General background: Microsoft Learn on document chunking ↗.

No. Very small chunks can lose context; very large ones can mix unrelated topics. The suitable size depends on the information and the intended retrieval process.

Overlap means repeating a little boundary text in neighbouring chunks to preserve context. It is a general chunking technique, not a promise that every CIRMS configuration uses it. More chunks or more overlap are not, by themselves, evidence of better knowledge.

A token is a small unit of text processed by a language model. Depending on the tokenizer, it may represent a word, part of a word, punctuation or another text unit.

A chunk can contain many tokens. A token count is therefore not a count of documents or chunks. Model input limits and the configured text-processing rules matter when choosing chunk sizes.

A vector is an ordered list of numbers. An embedding is a numerical representation produced from content, usually by an embedding model in an AI retrieval system.

Think of coordinates on a map: they allow a system to compare positions. With suitable semantic embeddings, related content can have similar representations. The numbers are not a readable answer, and their usefulness depends on the configured process.

General background: Microsoft Learn on embeddings ↗.

No. An embedding model represents content as numbers for tasks such as comparison and retrieval. A conversational language model generates a response.

GL4 can perform configured vector embedding as part of preparation without providing a chat interface. Conversational assistance and broader AI analysis belong to the planned GL5 direction. “AI-ready” and “chatbot available” are different claims.

Semantic means related to meaning. “Low disk space” and “storage almost full” use different words but describe related ideas.

A meaning-oriented retrieval method tries to find relevant content beyond exact wording. Similarity is not proof of truth or identical meaning. CIRMS semantic validation checks its configured retrieval preparation; it should not be confused with a human fact-check of every source statement.

Retrieval means finding relevant prepared information. Vector retrieval compares numerical representations; other retrieval methods can use words or structured filters.

In CIRMS, a configured route defines the scope and configuration through which prepared knowledge is selected and validated. It is not a network cable. Correct source relationships, eligible versions and approved vectors must agree with that scope.

General background: Microsoft Learn on vector retrieval ↗.

Lineage records where information came from and how it was prepared. Traceability is the ability to follow those links.

A lineage record is useful evidence, but it is not a substitute for checking access, freshness or the correctness of the original data.

Enrichment adds useful context, such as source identity, units or a category. Semantic tagging attaches meaning-oriented labels. A canonical model is a common structure used to make differently organised data consistent.

For example, agreeing whether a storage value is in bytes or gigabytes avoids an ambiguous number. In CIRMS, the actual result comes from configured metadata and preparation rules. These terms do not mean that GL4 automatically understands every department or invents a universal company data model.

RAG means retrieval-augmented generation. In this general AI pattern, a system finds relevant material and supplies it as context to a model before the model generates an answer.

GL4 prepares knowledge assets that may support such downstream use. A complete assistant also needs retrieval integration, a model, permissions and response controls. RAG is not a synonym for GL4 and does not mean a CIRMS GL5 assistant is already released.

General background: Microsoft Learn on RAG ↗. External examples are not claims of a built-in CIRMS integration.

These describe how accepted source data compares with the relevant earlier state: inserted is newly present, updated has changed, deleted has been identified as removed, and unchanged has no detected content change under the configured rules.

The available interpretation depends on row identity and change detection. With no stable key, an apparent edit may need to be represented as removed and newly present content rather than a stable-record update.

Because an existing document can change without becoming a new document identity. With stable source identity, an update creates new prepared content for the same continuing record.

New chunks are newly generated content pieces. Reused chunks are existing pieces that remain eligible under the relevant content and configuration checks.

Reuse avoids doing the same work unnecessarily. It does not mean old content is always reused: a changed document, chunking rule or other dependency can require regeneration. Read the new/reused counters together with the processing scope.

They count different things. One document version may produce several chunks. Historical versions and different configurations can also affect the totals, so source rows, documents, chunks and vectors should not be expected to have equal counts.

Generated means a numerical representation exists. Approved means it has passed the applicable eligibility and validation rules for its intended use.

A vector can exist without being current, approved or correctly linked to the required route. Therefore, a total vector count is not the same as a ready-to-use vector count. Older versions may also remain as history without being eligible for current retrieval.

A repeat run can validate the current state without creating new document content, chunks or vectors where existing assets remain eligible.

“No new content” can be a healthy outcome. It is not a reason to skip necessary checks, and changed configuration or invalidated approvals may still require processing even when the source values are unchanged.

GL4 refreshes source metadata and checks the expected preparation structure. A supported change can be processed under the applicable rules; an unsupported or inconsistent structure must be reported rather than silently treated as valid.

A dropped key may affect identity, while a changed column type can affect extraction or curation. The administrator should inspect the failing object and rule before rerunning. The FAQ does not promise automatic acceptance of every schema change.

No. An empty source has been successfully read and has no in-scope rows. A missing table, unavailable server or denied permission means that the source state could not be established.

Failure to read must not be interpreted as confirmation that all rows were deleted. A genuinely empty input also needs the applicable processing and readiness rules; it does not automatically satisfy every retrieval requirement. “No registered work” is a third, separate situation.

AI_READY is a CIRMS preparation status for a defined scope. It indicates that the applicable preparation and validation requirements have been met.

It is not an official certification, a guarantee of factual accuracy or a promise that an AI model will always answer correctly. To judge usability, also inspect source freshness, the latest execution outcome and any health issue.

They answer different questions. Readiness: is there an accepted prepared knowledge state? Latest execution: did the most recent run succeed? Health: is there an issue requiring attention?

Read these signals together instead of relying on one green status.

Start with the affected source object, stage number and recorded error. Check access, source structure, registration choices and the required configuration for that stage.

Resolve the cause and use the supported rerun procedure. Later stages that depend on failed output must not manufacture a success. Whether other objects continue and which assets are preserved depends on the processing rules; a failure is not a reason to rebuild every healthy source blindly.

Removing a record from the current knowledge state and erasing every historical copy are different operations. A source deletion can make its prepared content inactive or ineligible for current use while historical records remain under the configured lifecycle rules.

A separate retention or removal process is needed when history, derived assets and backups must be addressed. Do not treat an “inactive” label as proof that every copy has been physically erased.

The architecture is designed for modular integration with existing operational systems. A deployment assessment establishes the actual supported interfaces, authentication, permissions, data shapes and tasks.

Bring a list of the relevant databases, operating systems, applications and desired actions. A diagram containing “databases” or “applications” does not mean every vendor, release or API is supported automatically.

Yes, the architecture supports a scoped starting point. Begin with agreed resources and tasks, then evaluate additional modules, data sources or HERCULES environments as needs grow.

Broader coordination can use the HERCULES–ATLAS model. Expansion still requires capacity planning, access review and testing; “scalable” is not a promise of unlimited workload on unchanged hardware.

Any extraction or preparation workload can consume resources. The impact depends on data volume, the chosen change strategy, query design, scheduling and available capacity.

Agree a small initial scope, measure it, and choose an appropriate schedule before expanding. Incremental processing can reduce repeated work where it is supported, but there is no universal zero-impact guarantee.

People decide which resources are connected, what work is authorised and how results are reviewed. CIRMS provides execution results, checks, stages and reports to make that work inspectable.

Automation does not transfer responsibility away from the organisation. For planned AI assistance, people must also define acceptable use and review consequential recommendations before acting.

No. Access should match the agreed task. Reading source data, inspecting a service and changing a system require different permissions.

The deployment must define service accounts, allowed operations, network access and who can configure or run work. A failed access check should be resolved deliberately; it is not a reason to grant broad administrator rights without review.

No product feature is a blanket guarantee. CIRMS health checks, execution records and reporting can help teams inspect conditions and gather evidence.

Access controls, connection security, logging coverage, retention and operational procedures still need to be configured and verified for the deployment. A dashboard status is not a security certification, and this FAQ does not claim universal anomaly detection or a complete record of every user action.

Document history is not a replacement for a backup-and-recovery plan. Keeping a past document version does not prove that the databases, configuration or service can be restored after an incident.

Supported operational tasks may include backup-related work and checks, but restore procedures, recovery objectives and continuity arrangements must be agreed and tested. The multi-ATLAS model remains a planned architectural direction, not a guaranteed production failover service.

Prepared data belongs in the environment and services configured for the deployment. Registering a source does not, by itself, mean it is published on the internet.

Review where raw data, documents, chunks and vectors are stored, who can access them and which embedding services receive content. Do not assume that all processing is local, or that all data is sent to a cloud service: those choices must be established for the actual installation.

No. Encoding content as a vector is not encryption and is not a reliable way to make sensitive information anonymous.

Documents, chunks, metadata and derived representations should all be included in access and lifecycle decisions. Treat the knowledge pipeline as part of the organisation’s information environment, not as a place where data automatically loses its sensitivity.

Do not assume universal compatibility. The supported runtimes, modules, database platforms and integration paths depend on the installation and the functionality being delivered.

CIRMS has its own dashboard and report views. A requirement involving Python, Java, .NET, Power BI, Tableau or another tool should be checked explicitly, including the required interface and security controls, rather than inferred from an older marketing list.

CIRMS GL5 is planned development. The current website presents GL3 automation and GL4 AI Data Readiness separately from that planned intelligence extension.

Illustrations of AI assistance are concepts, not screenshots of a released GL5 chatbot. Availability, scope and delivery commitments must be confirmed as part of an actual product discussion.

The planned direction is to connect AI models and conversational assistance to the knowledge prepared through GL3 and GL4.

Intended uses include helping people find information, explore operational questions, review cross-department insights and consider recommendations. These are roadmap goals with human oversight, not a promise that every illustrated capability is currently implemented.

No. CIRMS should not be presented as Artificial General Intelligence or as an autonomous system that understands and controls everything.

Current GL3 and GL4 responsibilities are defined operational work and knowledge preparation. The planned GL5 scope is AI assistance on that foundation. Older references to an automatic transition to AGI should not be read as current functionality or a guaranteed future capability.

Not by itself. Creating embeddings applies a configured process to content to produce representations. It is different from training or fine-tuning a model.

A future assistant would need its own model and integration decisions. The provider’s handling of submitted content must also be reviewed separately; this FAQ does not promise that every possible provider has identical training or retention policies.

Choose a narrow, repeatable problem: for example, agreed operational checks and a clearly identified dataset that the team currently assembles manually.

Define the expected output, connect only the approved scope and validate the GL3 results. Where AI data preparation is relevant, register eligible sources in GL4 and inspect the complete run. Expand only after the team understands the output and its operating requirements.

Use the Contact page or email office@tohol.org with a short description of your environment, the operational problem and whether you are exploring GL3, GL4 or the planned GL5 roadmap.

A useful walkthrough follows one task and one source through the relevant screens. Ask what is already available, what needs configuration and what remains planned. Do not send passwords, private keys or confidential production datasets in an initial enquiry.