Aivis-OS System Architecture

Status and evidentiary logic of this document

This document is the canonical public system specification of Aivis-OS. It is neither an independent research report nor a marketing whitepaper. It defines the category, architecture, terminology, projection rules, measurement logic, and operating model of Aivis-OS.

The statements follow three clearly distinguishable levels:

Where a statement concerns effects on external systems, the control boundary is explicitly stated. Where it describes Aivis-OS’s own architecture, it is not a hypothesis about the market, but a definition of the system.

From document discoverability to answer reconstruction

Ranking has not disappeared. It has become less visible to the user.

Traditional search answers a query with a ranking of documents. Generative search systems can use the same or similar retrieval and quality systems, but then perform an additional transformation: they synthesize an answer from selected sources. Google explicitly explains that established SEO fundamentals remain relevant for AI Overviews and AI Mode. The claim that generative systems have completely eliminated ranking would therefore be false.

The strategic change lies elsewhere: the user does not necessarily see the ranking as a list. They see the result of a selection and condensation process. A source can be highly rated and still not be visibly cited. A brand can be mentioned even though its own domain does not appear as a source. A correct statement can be derived from the wrong entity or the wrong time period. And an incorrect statement can be phrased so plausibly that it reads like knowledge.

Discoverability remains necessary. It is no longer sufficient.

Four states that must not be confused

Aivis-OS separates four states that often collapse into one another in conventional visibility metrics:

This separation is not rhetorical sharpening. NIST AI 600-1 lists confabulation as a technical model risk. HaluEval examines plausible but not robustly supported answers. NumericBench documents persistent weaknesses in number recognition, numerical retrieval, comparison, and inference. Research on Knowledge Conflicts shows that conflicts between contexts and parametric knowledge can impair the trustworthiness and performance of language models.

A brand can therefore be visible and yet be structurally reconstructed incorrectly.

The GEO trap

With Generative Engine Optimization and AI Visibility, a new field of research and practice has emerged. Many visible offerings measure the output of generative systems: prompts are executed repeatedly; evaluated are brand mentions, positions, citations, sentiment, sources, or share of voice. This logic is clearly recognizable in today’s providers’ product descriptions, for example at Profound, Peec AI, or AI Visibility.

Such measurements are useful. The trap only arises when output observation is confused with root-cause remediation.

Monitoring can show that a model states an incorrect number. It cannot decide which of several numbers on your own domain applies to which context.

Monitoring can detect a missing citation. It cannot prevent the same entity from being exposed across forty URLs as forty separate identities.

Monitoring can measure a visibility trend. It cannot determine whether a correct answer is based on robust evidence or on statistical plausibility as long as it only counts names and keywords.

Aivis-OS refers to this reduction as the GEO trap: the visible output is optimized while the company’s own source state remains unmanaged. Aivis-OS calls the market-standard perspective on answers Outside-In. Its own architectural approach works Inside-Out: from the decided source state to verifiable external reconstruction.

Monitoring and Source Architecture do not exclude each other. However, they are not symmetrical. Monitoring observes the deviation. Source Architecture works on the space in which the avoidable cause lies. Aivis-OS therefore integrates monitoring as the fifth architectural layer—not as a replacement for the first four.

The category: Domain-based AI Source Integrity

Definition

Aivis-OS uses the term Domain-based AI Source Integrity for the following target state:

An organization maintains identities, facts, relationships, scopes, and temporal states on its own domain so consistently, traceably, and machine-readably that external systems can retrieve and reconstruct them without avoidable ambiguity.

The term is an Aivis-OS category. It does not denote a W3C, ISO, or industry standard. Nor is its subject the entirety of an organization’s information world. Aivis-OS starts with the digital property that an organization itself publishes and can change: its domain, including the HTML pages, PDFs, and other public resources provided there.

What “primary source” means

Aivis-OS pursues the goal of making the organization’s own domain the primary source when AI speaks about the organization. Primary source here means:

• The organization maintains the approved reference state on its own domain.
• Identity, statement, context, and provenance are traceable there.
• External systems can retrieve this state and cross-check it against other sources.
• Corrections start at the source, not only in a downstream answer dashboard.

Primary source does not mean that every model selects the domain in every answer or cites it visibly. It means that, where the organization actually has control, it establishes a robust reference baseline.

The controllable chain

Aivis-OS models the information chain into two fundamentally different spaces:

The organization’s controllable space

Institutionelles Wissen → publizierter Korpus → kanonische Assertions → sichtbarer Content → Machine Interface

The probabilistic space of external systems

Crawling / Retrieval → Auswahl / Gewichtung → Kontextbildung → Synthese → Zitation / Antwort

Evidence Monitoring connects both spaces in reverse:

Antwortbefund → Fehlerklasse → betroffene Architekturebene → Remediation

For this analysis, Aivis-OS uses the terms Entity Recognition and Evidence Weighting: external systems must assign entities and select or weight evidence before they synthesize an answer. The terms describe the analytically relevant functions, not a universal phase model implemented identically by all providers. Where test conditions can be distinguished, Aivis-OS refers to a purely parametric answer path as Case L and a web-based path as Case L+O.

This separation is the core of Deterministic source, probabilistic reconstruction. Aivis-OS makes no claim that external systems become deterministic. It ensures that the organization itself does not send multiple undecided states into the same reconstruction space.

Five design principles

Aivis-OS summarizes the priority of explicit structure in the phrase Structure beats ranking. This phrase does not claim that ranking is ineffective. It describes a design decision: ranking can bring a document into the selection space. Structure helps determine how unambiguously its identity, statement, and relation are preserved after retrieval, extraction, and synthesis.

The five-layer architecture

Aivis-OS is not a single markup module and not a monolithic dashboard. It is a five-stage architecture model in which each layer addresses a different source of loss or error between institutional knowledge, the published domain, and the external AI answer.

The layers form a control loop. Layers 1 through 4 establish the source state. Layer 5 tests its external reconstruction. An output error is not only counted, but traced back to the layer where a correction is possible.

Layer 1: Identity – Cluster-Level Entity Inventory

A URL is a location. It is not an identity.

Externally evidenced finding

JSON-LD can uniquely name nodes. The W3C specification JSON-LD 1.1 defines @id as a node identifier via an IRI. Schema.org sameAs points to a resource that uniquely denotes the same identity. Wikidata, LEI, ISIN, or ORCID provide—depending on the entity type—additional persistent identifiers.

These standards do not guarantee that any given AI system will correctly recognize an entity. However, they demonstrate something fundamental: identity can be referenced explicitly, rather than having to be guessed from spelling, URL, or textual proximity alone.

The source problem

Historically grown websites often treat identity implicitly per page. The same organization can appear as a legal entity, group, brand, national subsidiary, or short form. Multilingualism creates additional variants. Old documents use former names. Individual plugins or authors create new schema nodes with new IDs per URL.

Humans can consolidate many of these variants from context. Machines, by contrast, receive separate signals. Aivis-OS refers to the resulting source-side fragmentation as Identity Drift. Within the Aivis-OS methodology, the term Ambiguity Penalty describes the operational risk that ambiguous identity degrades the stability of attribution and relation; it is not a disclosed universal parameter of a specific LLM provider.

Aivis-OS architectural decision

Aivis-OS decouples identity from the local URL and introduces a Cluster-Level Entity Inventory. Each relevant entity receives a Golden Record with:

• a persistent internal identity;
• the most specific factually applicable Schema.org type;
• canonical name and permitted name variants;
• language, brand, and historical variants;
• external identifiers and references, where unambiguous and appropriate;
• relationships to organizations, people, products, places, reports, or events;
• documented provenance and governance responsibility.

An Aivis-OS internal ID can be generated according to the following pattern:

entity://{cluster_id}/{schema_type}/{slug}-{short_hash}

This syntax is an Aivis-OS convention, not a W3C standard. Its function is persistence: the same entity retains the same internal reference across URLs, languages, and updates. In the public projection, standards-compliant IRIs and external IDs can additionally be used.

Controlled outcome

Layer 1 prevents the organization’s own architecture from continuously exposing the same entity as a new, unconnected entity. For the first time, the organization has an inventory of what it claims to exist in machine-readable form.

Persistent identity alone guarantees neither retrieval nor citation. But without persistent identity, every downstream system must probabilistically infer equivalence again. Aivis-OS removes this avoidable uncertainty at the source.

Layer 2: Context & Meaning – Semantic Graph Layer

A model cannot know which of two published corporate statements the company itself considers valid.

Externally evidenced finding

Knowledge conflicts are not a theoretical edge case. The survey Knowledge Conflicts for LLMs distinguishes conflicts between context and model knowledge, between multiple contexts, and within parametric knowledge. The ACL work Blinded by Generated Contexts shows that, in the conflict situations studied, models can prefer incorrect generated contexts over correct retrieved contexts; the authors identify disrupted completeness of retrieved contexts due to segmentation as one factor. Research on dynamic facts additionally examines the problem of temporally changing statements.

The finding is immediately relevant for companies: an old annual report, a current landing page, a press release, and a national subsidiary can state different numbers without all statements being wrong in the same context. The machine does not know the internal logic of applicability.

Variation is not automatically a contradiction

Aivis-OS strictly distinguishes between legitimate multiplicity and real conflict.

An annual report from 2024 and an annual report from 2025 may contain different employee counts. A former price remains correct as a historical value if its time period is identifiable. A group metric and a subsidiary metric are both legitimate if their organizational scope remains unambiguous.

A contradiction arises only when two statements about the same subject, in the same context, and for the same period of validity cannot both be true at the same time.

Aivis-OS architectural decision

The Semantic Graph Layer models statements as typed assertions rather than loose text fragments. An assertion can include, among other things:

• subject, predicate, and object;
• source and provenance;
• organizational, geographic, or product-related scope;
• temporal validity and effective date;
• status, approval, and responsibility;
• evidence or confidence rating within the respective project;
• relationships to competing, historical, or derived statements.

Competing assertions are not silently overwritten and not decided by frequency. They are consolidated into conflict groups, reviewed by subject-matter experts, and resolved for a defined context.

Aivis-OS follows the principle:

Internal Multiplicity, External Determinism.

Internally, the organization may have multiple historical, regional, or context-dependent statements. Externally, exactly the approved state is projected for a defined context. History is not deleted. It is made distinguishable.

Finished States

The Semantic Graph Layer does not lead to a timeless, static “truth”. It leads to a finished state for the known context.

Finished means:

• known entities are decided;
• competing statements are resolved or qualified as legitimate variants;
• scopes and temporal states are specified;
• public exposure matches the approval;
• open interim solutions do not become a permanent state.

If the organization changes, a new state is created. A new product, a new metric, a renaming, or a regulatory change does not make the earlier state unfinished. It triggers a new decision.

Controlled outcome

Layer 2 turns a historically grown body of statements into a manageable reference baseline. It does not create a universal claim to truth. It documents which statement the organization has approved for which context, why it applies, and what it is based on.

Software can detect and structure conflicts. It cannot autonomously decide institutional applicability. Therefore, subject-matter governance is not an add-on to the architecture, but a necessary component of it.

Layer 3: Retrieval Resilience – Transport-Safe Content Layer

Information can be visible to humans and still be incompletely transportable for machines.

Externally evidenced finding

In machine processing, a web page does not necessarily remain intact as a coherent visual page. Content is extracted, segmented, vectorized, ranked, and inserted into context windows. Meaning can be lost in the process.

Three independent research findings are particularly relevant here:

• Lost in the Middle shows that language model performance can drop significantly when relevant information is in the middle of long contexts rather than at the beginning or end—even for models with long context windows.
• Late Chunking describes that separately generated chunk embeddings can lose context from surrounding text segments, and achieves better retrieval results when the full context is considered before segmentation.
• Research on table retrieval and table understanding shows that tables must not be understood as mere linear character sequences. Structure, row, column, and header relationships are part of their meaning; flat decomposition can damage this mapping. See, for example, TableRAG.

Aivis-OS refers to the transition between the visible page and machine-usable information as the Ingestion Gap. The resulting loss of context, relation, or unambiguity is called Retrieval Entropy by the system.

Tables are not the problem. Implicit relationships are.

A table can work excellently for humans. It becomes problematic when the meaning of a value derives only from its spatial position and, after extraction, it is no longer clear which value belongs to which product, time period, country, or attribute.

An isolated fragment such as

24'700 | 2025 | Europa

is hardly reconstructable in a robust way without headers and context.

More transportable is a statement such as:

“As of December 31, 2025, the corporate group employed 24,700 people in Europe.”

Aivis-OS does not require abolishing tables. It requires that business-critical relationships do not exist exclusively in the visual grid.

Aivis-OS architectural decision

The Transport-Safe Content Layer breaks down relevant statements into atomic, self-contained, and explicitly related units of information. This includes:

• unambiguous naming of the subject;
• value and unit;
• time period, effective date, or validity duration;
• organizational, geographic, or product-related scope;
• explicit relation instead of purely visual proximity;
• visible marking of historical, archived, or restricted statements;
• sufficient local context so that an extracted fragment remains understandable.

Atomic does not mean maximally short. A unit of information is atomic when it can be correctly understood without unnecessary dependence on distant layout or text components.

Frontend-visible exposure

Transport-Safe Content remains visible to humans. The machine-readable layer clarifies and relates the visible content; it does not replace it with a divergent parallel truth.

This rule has an external compatibility basis: Google requires that structured data represent the visible page content, not be misleading, and not mark up information that remains invisible to readers. For dynamically generated markup, Google additionally notes that duplicated information increases the risk of discrepancies between page content and structured data.

Aivis-OS generalizes this principle as Content Parity:

What machines receive as the canonical state must be discoverable and traceable for humans on the published source.

Controlled outcome

Layer 3 reduces the dependence of business-critical statements on layout, position, and implicit context. It does not promise a universally optimal chunk size for every model. It establishes a more robust source state whose transportability can be tested against the real corpus.

Layer 4: API & Exposure – Machine Interface Layer

What an organization can state explicitly should not be left for a machine to guess unnecessarily.

Externally evidenced finding

HTML is the visible publication layer of a website. Structured data complements it with named nodes, types, and relationships. JSON-LD 1.1 provides a W3C-standardized data model for this. Google recommends JSON-LD for structured data because it is comparatively easy to implement and scale, and recommends the most specific factually applicable Schema.org type.

This does not imply that every LLM fully processes or prefers JSON-LD. However, it does imply that an organization can publish entities and relationships in a standardized, explicit way, rather than forcing them to be derived exclusively from unstructured HTML.

The function of the Machine Interface Layer

The Machine Interface Layer projects the approved state of the Semantic Graph as JSON-LD onto the relevant URLs. The website remains a website. It is additionally treated as a machine-oriented publication and projection layer.

Aivis-OS also uses the metaphor of a public read-only interface for this. This does not mean a transactional API with endpoints, authentication, rate limits, or an SLA. It means a stable, publicly retrievable projection of what the organization has approved for a specific context.

Three classes of rules

Aivis-OS explicitly distinguishes external standards, compatibility rules, and its own projection conventions:

This distinction prevents two errors: Aivis-OS does not present its own conventions as an external norm. Conversely, it does not treat external standards as a non-binding matter of style.

Aivis-OS projection rules

1. Specific Type Selection: Each entity receives the most specific factually applicable Schema.org type. A MedicalClinic is not reduced to the generic Organization without good reason. Specificity is not an end in itself; it is intended to sharpen the semantic statement.
2. ID Persistence: The same entity retains the same reference across URLs, languages, and updates. IDs are not regenerated with every page build.
3. Focus Node + 1 Hop: The central entity of a page is projected in full. Directly connected entities are referenced sufficiently without nesting the graph arbitrarily deep. This rule limits redundancy and keeps the projection verifiable.
4. Coherent Graph Projection: The relevant nodes are published as a coherent @graph in a separate JSON-LD script, preferably in the document head. W3C and Google do not require a single block nor placement in the <head>; Aivis-OS standardizes this form for consistency, maintainability, and technical control.
5. Content Parity: The graph describes the same approved state as the visible content. Structured data must not create a counter-truth that is not published.
6. Scoped Serialization: The entire company-wide graph is not repeated on every URL. Each page receives the projection required for its focus and its direct relations.
7. Validation and Traceability: Each projection remains traceable back to its Golden Record, its assertions, and its sources. Syntax validity alone is not sufficient; semantic provenance must remain verifiable.

Controlled outcome

Layer 4 makes the approved source state explicit, typed, and referencable. It improves the organization’s own exposure, not the processing policy of third-party providers. Aivis-OS therefore does not guarantee that a specific system fully consumes JSON-LD or cites it visibly.

The decisive architectural contribution comes earlier: the organization no longer forces external systems to guess the identities and relationships that it can model unambiguously itself.

Layer 5: Observability – Evidence Monitoring

A correct answer is not yet proof of a correct source architecture.

Why mention-only measurement is not sufficient

Generative answers can be plausible, correct, or visible and still rest on an unstable foundation. NIST treats confabulation as a model risk. HaluEval examines hallucinations that are not robustly supported. DateLogicQA addresses temporal reasoning, NumericBench fundamental numerical capabilities. This research does not prove the completeness of Aivis-OS measurement logic. It demonstrates the reason why mention and sentiment alone are not sufficient for business-critical facts.

Aivis-OS distinguishes three recurring blind spots:

• Evidence Blindness: The answer is plausible, but its source or derivation remains unstable.
• Semantic Blindness: The organization is mentioned, but role, affiliation, identity, or relationship are incorrect.
• Numerical Blindness: Number, unit, ratio, time period, or effective date are reconstructed incorrectly or incompletely.

Dual-layer probing

Evidence Monitoring uses two test layers:

• Layer A – User Simulation: realistic, sometimes imprecise prompts as they occur in real usage situations;
• Layer B – Forensic Probing: targeted prompts that stress-test identity, relation, source, number, time period, and scope.

Aivis-OS refers to the difference between superficial visibility and forensic robustness as the Integrity Gap. A brand can appear stably visible in Layer A and, under a precise follow-up question in Layer B, flip to the wrong legal entity, subsidiary, metric, or source. Aivis-OS calls this state Bubble Visibility.

Four measurement dimensions

Measurement protocol

Aivis-OS treats impact not as an impression, but as a versioned test problem. A robust measurement protocol includes at least:

1. Canonical Truth Set: The assertions to be tested are derived from the approved Assertion Layer. Each expected answer includes entity, scope, time period, and evidence.
2. Versioned prompt set: User simulation and forensic prompts are fixed. Changes to the set are documented so that time comparisons are not distorted by changing questions.
3. Documented system context: The model or product, search mode, language, region, date, time, and other identifiable configurations are logged. Where possible, Aivis-OS distinguishes between the parametric response path and web-backed retrieval.
4. Repeated measurement: A single run is not considered a stable finding. Prompts are repeated and tested across multiple systems because answers are probabilistic and provider processes are dynamic.
5. Time points T0, T1, and T2: T0 documents the baseline before the intervention. T1 tests the first measurable phase after exposure. T2 checks whether an effect or error pattern remains stable. Depending on the project, additional measurement points may follow.
6. Error classification: Deviations are not coded only as “correct” or “incorrect”, but assigned to their error class and the architecture layer likely affected.
7. Remediation Trace: Each correction is traced back to a corpus change, assertion decision, content adjustment, projection, or external reference. This keeps it clear what was actually changed.
8. Causality discipline: A temporal improvement after an architectural measure is an indicator of impact, but not automatically universal proof of causality. Aivis-OS separates project-specific evidence from general model claims.

Source Anchoring Score

Aivis-OS can consolidate the measurement dimensions in the internal Source Anchoring Score (SAS):

SAS = Attribution Weight × Integrity Weight × Citation Rate

The Attribution Weight reflects the stability of correct entity attribution. The Integrity Weight aggregates, on a project basis, Entity Logic, Evidence Consistency, and Temporal & Numerical Precision. The Citation Rate measures how often the defined source basis is explicitly referenced, provided the tested system outputs citations.

An SAS of ≥ 0.9 can be used as an internal release threshold within a clearly defined, versioned test design. It does not mean that “truth is deterministically anchored in the model”. It means that, under the documented conditions, the configured test object has achieved high stability.

SAS is an Aivis-OS verification instrument, not an independent industry standard. Its evidentiary value arises from transparent prompt sets, repetitions, weightings, thresholds, and the documented Canonical Truth Set.

Remediation instead of reporting

Evidence Monitoring does not end in the dashboard. A finding becomes a Remediation Trigger:

• incorrect entity → check Layer 1;
• incorrect scope or time period → check Layer 2;
• lost context or table reference → check Layer 3;
• missing or contradictory projection → check Layer 4;
• unstable or insufficient test design → check Layer 5.

This closes the loop. Aivis-OS does not only measure what AI says. It uses the response as a forensic indicator of the state of the source.

The 4C Evaluation Framework

The presence of structured data is not a maturity level. What matters is whether a domain can be governed as a source.

The 4C model is Aivis-OS’s evaluation framework. It assesses the state of the source across four interdependent dimensions:

Confirmed does not mean that an external identifier confirms every factual statement. A Wikidata QID can reference identity; it does not automatically prove a company metric. Aivis-OS therefore separates identity anchors, source provenance, and domain approval.

4C is a proprietary Aivis-OS framework. Its purpose is not to decorate a website with an abstract score. It makes visible which decisions are missing before a reliable machine-readable exposure.

From the corpus to the approved state

Truth before enrichment.

Aivis-OS is not a plugin that automatically adds additional markup to unverified content. Structured data increases the explicitness of a statement. If the statement is incorrect, incomplete, or contradictory, this does not create truth; it exposes the error more precisely.

This is why Aivis-OS starts before JSON-LD.

Operational sequence

1. Corpus Inventory: Capturing the relevant HTML pages, PDFs, files, and other published resources. The corpus is treated as a domain asset, not as a loose list of individual URLs.
2. Page and domain classification: Classification of organization type, page function, domain scope, stakeholder context, and jurisdiction. Extraction without orientation produces typed individual findings without a reliable system logic.
3. Entity and assertion extraction: Identifying relevant organizations, people, products, places, reports, events, metrics, and statements.
4. Deduplication and entity resolution: Consolidating variants into canonical Golden Records. Name similarity is not automatically mistaken for identity equivalence.
5. Conflict groups: Bundling competing, historical, or explanation-requiring statements by subject, scope, and time period.
6. Canonical decisions: Domain approval of what applies in a defined context. Old values can legitimately remain as historical values; true conflicts are decided.
7. Canonical Assertion Layer: Storing the approved state with provenance, scope, temporal reference, and accountability.
8. Transport-Safe Content: Adjusting visible content where subject, relation, unit, time period, or context may be lost during extraction.
9. Machine Interface Layer: Projecting the relevant entities and assertions as a consistent, typed JSON-LD graph.
10. Forensic Measurement: Testing attribution, entity logic, evidence, and temporal and numerical precision against the Canonical Truth Set.
11. Remediation and attestation: Tracing deviations back into corpus, graph, content, or projection; documented approval of the achieved state.

The principle of finished states

Initial onboarding brings the known corpus into a decided, approved state. Finished does not mean the organization will never change again. It means that, for the currently known state, no unresolved interim solution remains as ongoing operation.

For some organizations, this state remains stable for a long time. For others, products, people, metrics, or regulatory requirements change continuously. Operations become relevant only where change creates a new need for decisions.

Aivis-OS therefore distinguishes between:

• Onboarding: establishing the first finished state;
• Governance: moving new facts into the next finished state in each case.

Attestation and Conflict Watch

Two functions secure operations:

• The Attestation tests a defined prompt set at specified intervals across multiple AI systems and documents reconstruction stability.
• The Conflict Watch monitors the organization’s domain corpus for new statements, variants, or contradictions that could change the approved graph.

The Attestation observes the external effect. The Conflict Watch observes the internal source. Only together do they form a closed governance cycle.

Deployment and operating model

Three deployment paths

Aivis-OS provides three primary entry paths:

A pilot is not a scaled-down promise of rapid visibility. It tests whether the organization can actually manage the necessary decisions, roles, approvals, and update processes.

Five decision-making spaces

Regardless of the entry path, decisions must be made in five areas:

1. Entity Inventory: What exists canonically, and how is it identified?
2. Semantic Graph: Which statements and relationships apply in which context?
3. Content Parity & Retrieval Resilience: Where and how is the approved state published visibly and in a transport-safe way?
4. Machine Interface: Which parts of the graph are projected on which URL?
5. Evidence & Monitoring: How is it verified that external systems reconstruct the source state stably?

Managed Architectural Service

Aivis-OS is not a monolithic self-service SaaS. The reason lies in the nature of the problem: software can crawl, extract, compare, group, model, and project. It cannot autonomously decide which statement should apply from a regulatory, legal, domain, or institutional perspective.

The operating model therefore combines three competencies:

• Methodology and governance: architecture, decision logic, and quality assurance;
• Technology: pipeline, data model, technical integration, and Machine Interface;
• Implementation & Growth: organizational introduction, rollout, and market integration.

The architecture, methodology, and original software specification were developed by Norbert Kathriner; methodological governance is provided by Boutique für digitale Kommunikation GmbH. epoint is responsible for software development and technical integration. The current Implementation & Growth partners are listed on the Aivis-OS contact and network page. Partner roles may change operationally; the system architecture remains independent of this.

Burden of proof, limits, and falsifiability

A new category does not become credible by adapting to the existing category space. It becomes credible by making its distinction precise and verifiable.

Aivis-OS distinguishes three types of claim:

What Aivis-OS controls

• the inventoried domain corpus;
• the canonical identity of relevant entities;
• the domain decision on competing statements;
• provenance, scope, and temporal reference;
• visible content parity;
• its own machine-readable projection;
• the test design and the documentation of identified deviations.

What remains outside direct control

• whether and when a provider crawls or retrieves the domain;
• which sources an external system selects and weights;
• how parametric knowledge and retrieved evidence are combined;
• whether a source is cited visibly;
• which model, product, or ranking changes a provider makes;
• which contradictory third-party sources persist outside the organization’s own domain.

Conditions under which a measure is considered not confirmed

An Aivis-OS measure is not considered effective merely because it was implemented correctly from a technical standpoint. Its external effect is limited or not confirmed if, for example:

• the tested system does not retrieve the source;
• attribution does not improve in repeated tests despite stable identity;
• a content or graph change shows no measurable improvement compared to T0;
• external, authoritatively rated conflict sources override the domain information;
• the organization itself approves an incorrect canonical state;
• the measurement design is too small, inconsistent, or insufficiently documented;
• an improvement occurs only in a single model, time point, or prompt and remains non-replicable.

These conditions do not weaken the architecture. They prevent Aivis-OS from turning a plausible theory into an unverifiable promise of salvation.

The actual control boundary

Aivis-OS does not make external systems deterministic. It makes the organization’s source state decidable, exposable, and verifiable.

This is not a modest substitute. It is the prerequisite for being able to distinguish whether an external error originates in the organization’s own source, a third-party source, retrieval, conflict resolution, or the model’s synthesis.