How KAG could extend AI Office: from tender requirements to building operations

Before entering a tender, a manager asks a simple question: “Can we meet these requirements, and what evidence supports that?” The answer has to be assembled from specifications, catalogs, supplier offers, equipment manuals and internal approvals. Each file may be clear on its own. The difficulty lies in the relationships between them.

OpenSPG KAG is interesting for this work: connecting objects, conditions and evidence, then helping answer questions over that structure. For AI Office, it is a possible extension from document retrieval to examining a specific working case.

Our earlier article introduces knowledge graphs and KAG. This practical follow-up examines tasks, a possible integration and criteria for a useful pilot. Official project information was checked on October 15, 2026. The KAG workflows below are proposals for developing the service, not an announcement of an implemented module.

KAG—Knowledge Augmented Generation—is a specific open-source framework based on OpenSPG and language models. It combines a knowledge graph, original text chunks and retrieval. A question can be decomposed into steps involving exact matching, text retrieval, relationship traversal and calculations. OpenSPG · KAG official repository and architecture ↗

The research describes mutual indexing between graphs and text, alongside hybrid reasoning. That provides an architectural foundation rather than a guarantee of correct answers over arbitrary corporate data. KAG: Boosting LLMs in Professional Domains via Knowledge Augmented Generation ↗

The proposed AI Office workflow is to identify the working object, retrieve related requirements and facts, check sources and currency, perform permitted calculations, then show a conclusion and unknowns. At each step, distinguish retrieved information, rule-based calculations and model suggestions.

Start with a process in which employees repeatedly compare the same types of objects. Define the required data and a result that a person can check for each direction.

These scenarios need different integrations. Examining an uploaded document set can start without a CRM connection. Answering a question about inventory or completed work needs a trustworthy source of those states. KAG does not create missing data or establish that an external system’s record is current.

Consider a fictional example. A specification requires delivery within ten working days, a particular equipment variant and a set of supporting documents. The company has a supplier offer and a series-level manual. A manager needs a list of supported requirements and gaps.

A future knowledge model could connect the tender, individual requirement, offered item, its variant and a supporting document passage. A relationship extracted from text initially remains a candidate for checking. A matching series name does not establish the properties of a particular item.

The useful output is an evidence matrix and questions for responsible people. Ten working days and twelve calendar days cannot automatically be treated as equivalent: the starting conditions and calendar matter.

Missing evidence should not become a categorical rejection, and the system should not invent compliance to make a summary look complete. An authorized person decides whether to participate and accepts legally significant conditions. KAG helps prepare the material for that decision.

In sales, a graph could help answer “what changes if we replace this item?” A prepared proposal relates to a customer request, catalog row, selected configuration, calculation and approval. A replacement might affect price, timing, compatibility and an already approved commitment.

A future AI Office workflow could show related objects and the evidence for each dependency. For example, a new equipment variant requires a different mounting kit. The assistant finds support in documentation and proposes reviewing the offer’s contents. If compatibility is not established, it asks for clarification.

Amounts, discounts and VAT are calculated by application code under approved rules. Model prose does not replace calculation. A new proposal version needs its own approval: changes to a graph or catalog do not rewrite previously approved terms.

An apartment, house or office suggests another domain model: room, installed equipment, serial number, manual version, warranty, maintenance procedure and service record. This is particularly useful when similar-looking devices have different variants.

Suppose a technician asks which documents apply to a ventilation unit in a particular room and what needs checking before service. Searching by model name might return a general manual. Relationships to the installed instance could help select the appropriate revision and identify missing information.

This knowledge layer could support work preparation, handover to a new contractor and change-history retrieval. It does not inherently collect sensor readings or control equipment. Telemetry, facilities supervision and smart-home commands are separate integrations with their own operating requirements.

A digital property record and engineering-system connections are possible developments of AI Office services, not implemented prototype features.

Support could link a case to a device model, software version, known incident and current instructions. Similar error wording becomes the start of retrieval; applicability is checked against the actual configuration. A specialist’s answer should show those conditions.

For employee training, a graph could connect a role, procedure, permitted action and approved exception. A new employee receives the working procedure and grounds for escalation. Each procedure needs an owner and effective date: a well-connected obsolete instruction remains obsolete.

For the Analyst Council, a promising use is preparing a shared fact set: project requirements, their supporting documents and contradictions. Roles discuss a checkable foundation, while a manager sees references and gaps. The graph does not make council roles independent experts or validate their interpretations.

A practical integration begins with one process. Define object and relationship types, such as requirement, item, variant, document and evidence. OpenSPG provides semantic schemas, knowledge construction and logical rules; the business model still needs to be designed for the task. OpenSPG: semantic modeling, knowledge construction and rule reasoning ↗

Knowledge preparation should be separate from answering a user. First, import authorized sources, extract candidate facts, check identifiers and preserve evidence. Verified relationships can then be made available to retrieval. Incorrect relationships should be correctable with an understanding of which outputs they affected.

A proposed integration could add a separate KAG service with a narrow read interface alongside AI Office’s existing retrieval. It returns objects, relationships and evidence. The application checks user permissions and supplies permitted material to the model for explanation. This separation, its load and storage compatibility still need evaluation.

Each derived fact needs a source, version, effective time and review status. A document change must identify what to recompute or mark stale. Access revocation must remove restricted information from answers, summaries and saved results. These are integration requirements, not automatic consequences of installing KAG.

KAG’s code includes an Ollama client for language models and a separate Ollama embedding client. Embeddings are numerical text representations used in retrieval. These provide a technical foundation for local configuration without establishing any model’s quality on a particular task. KAG source snapshot: Ollama language-model client ↗ KAG source snapshot: Ollama embedding client ↗

Model selection should distinguish object and relationship extraction, search representations and answer generation. Each stage needs checks for identifier accuracy, units and variants, table handling and grounded conclusions. A compact model might suffice for a narrow stage; testing establishes this rather than parameter count alone.

The official example configuration sends generation and extraction to DeepSeek’s API, and embeddings to SiliconFlow. Installing the project on an office server therefore does not itself establish a closed environment. Sensitive data requires configuring and checking every processing destination, including imports, retrieval, diagnostic logs and additional tools. KAG examples: model endpoints, graph construction and question answering ↗

Index construction, graph storage and updates also create load. Size the server after examining the corpus and user count; we do not claim measured KAG throughput on a particular AI station.

The current AI Office prototype implements permission-aware document retrieval, source versions and passage references. It handles text PDFs and DOCX, works with Excel/CSV catalogs, calculates proposals through checkable code, binds approval to a particular version and creates a local task. The Analyst Council uses three to five roles of one configured model.

Full OpenSPG KAG integration, a general object graph, a tender matrix and change-impact analysis are not implemented. Retrieval uses Qdrant and structured workflow records use SQLite. There are no production email, CRM or accounting connectors; scanned-document recognition is also outside current document processing.

KAG’s open-source code is distributed under Apache 2.0. A complete solution still requires checking model and dependency terms, maintenance and updates. Open source helps inspection and adaptation; deploying it against company data remains a separate undertaking. KAG source snapshot: Apache License 2.0 ↗

We would start with one recurring question, such as: “Which requirements in this document set are supported by the selected offer?” A company specialist prepares a reference assessment, including ambiguous cases and appropriate clarifying questions.

Compare three approaches: current retrieval, retrieval with ordinary structured queries, and KAG. Hold documents, permissions and assessment criteria constant. This helps identify the contribution of relationships and whether a simpler solution is sufficient.

• Check the correctness of matches and applicability of supporting passages.
• Count omitted requirements, invented relationships and unsupported categorical answers.
• Change a document version and check whether stale evidence is identified.
• Revoke access and check that restricted information is absent from new and saved results.
• Measure human review time, response latency and knowledge construction and maintenance costs.

Success means a checkable result with understandable maintenance costs. If the same dependencies are repeatedly needed and a graph helps maintain them, KAG becomes a justified next step. If the answer lives in one instruction or a simple table query suffices, an additional layer may be unnecessary.

For AI Office, KAG’s value would be connecting fragmented material into an evidence base for a specific process. Start with your document set and a question that currently needs manual assembly. A bounded pilot can establish which relationships help, what needs checking and whether the solution should expand.