Help Knowledge

Use Help Knowledge to turn saved Actualog Help Content into the knowledge base that Hex uses for answers. It helps Hex explain Actualog terms and application logic, give task-oriented instructions, and provide trusted Help links and authorized application-page links.

This workflow prepares answers only. It does not allow Hex to execute application tasks.

Start here: how to use this page

Use this page to answer three questions in this order:

1. Can Hex answer from Help Knowledge now?
2. What happened during the last update or rebuild?
3. What should I do next?

Begin with What should I do now? at the top of the page. It combines the current knowledge status, the latest job result, and the Azure Search readiness check into one recommendation.

Use the rest of the page as follows:

1. Read What should I do now? and follow its recommendation.
2. Check Current Help Knowledge index to see whether Hex can use the current knowledge version.
3. Check Last update or rebuild only when you need to understand the latest operation.
4. Use Answer quality diagnostics to check what complete article Hex would receive for a question.
5. Read Rebuild cost planning before a full rebuild. It is an estimate and makes no AI call.
6. Open Technical version details or Technical job details only when diagnosing a problem.
7. Choose the compiler and index budget under Build settings before starting a command.
8. Open Technical details: Azure Search usage and physical indexes only for quota or cleanup work.

Status and action

What the content numbers mean

• Indexed answer articles counts compact Azure Search records. Under Help Knowledge retrieval v4, each record represents one complete Answer Article, not a heading fragment or arbitrary character chunk. When the index is healthy, the page shows available of expected.
• Knowledge subjects are concepts, pages, tasks, integrations, commercial rules, or policies that Hex can discuss. A source Help document can support several subjects, and one subject can use evidence from several Help documents.
• Atomic answer units are the smallest titled pieces stored in SQL. Their explicit types remain separate: a Definition explains one term, for example what an Effective Template is; a Key fact is one verifiable assertion, for example that only product-level categories can have a Product Name Template; a Business rule / condition says what is allowed or required; and task steps, UI elements, examples, exceptions, and supporting context keep their own roles. A Definition is not counted as a Key fact.
• Answer articles are small but complete answers assembled from ordered typed units. They can explain a concept, solve a task, describe a page, compare terms, document a policy, or answer a reference question. One claim may support more than one article when the context requires it.

These values are diagnostic counts, not targets that an administrator must optimize. A larger number is not automatically better. Use them to notice an unexpected empty build or a large unexplained change after an update. For the same active v4 version, the expected search-document count should normally equal the Answer Article count.

Answer quality diagnostics

Use Answer quality diagnostics before asking the conversation model to write an answer:

1. Select Refresh quality scan after a build or Help edit.
2. Enter a representative question under Test a question.
3. Leave Include semantic vector off when testing a canonical term, exact alias, page target, or lexical match. Turn it on only when you intentionally want to test hybrid retrieval; this option makes one call to the configured embedding model.
4. Select Analyze retrieval.
5. Confirm that Selected complete Answer Articles contains the small, complete article needed for the question, and that Atomic answer units contain the definition, facts, rules, steps, caveats, and expected source citation needed before answer generation.

The full quality scan is manual. Opening this page and normal build-progress polling do not run its SQL analysis. Select Refresh quality scan only when you need these measurements.

This diagnostic stops before the answer composer. It does not ask the conversation model to generate text and it does not send diagnostic data to Azure telemetry.

The four deterministic answer-unit gates make no AI call:

• Source retention reports how many captured structural Help blocks are represented by at least one unit. This is structural coverage, not proof that every proposition inside a long block was preserved.
• Evidence provenance reports units with accepted source bindings.
• Atomic shape reports titled units that are at most 420 characters, contain about two sentence-like statements, and do not contain a multi-item list. This is a conservative shape heuristic, not a truth score.
• Review safety reports units without compiler review flags.

Semantic unit mix keeps Definitions, explicit Key facts, Business rules / conditions, Task steps, UI elements, Examples, Exceptions, and Context / needs classification separate. The displayed value is likely atomic / total for each type.

The other quality cards help decide what to correct:

• Subjects without article should be zero. A non-zero value means Hex knows the subject but has no complete article it can hydrate.
• Orphan answer units should be zero. A non-zero value means source knowledge was not included in any Answer Article.
• Article risks reports fragmentary, incomplete, or oversized articles.
• Article size · answer units shows minimum, median, 95th percentile, and maximum article sizes. Use it to find articles that are suspiciously small or broad; do not optimize for the lowest number.
• Help sources / article shows whether articles use one source or combine several related Help documents. Several sources are valid when they support one coherent answer.
• Canonical definitions shows concept subjects with an explicit Definition unit. A Key idea heading or the first paragraph is not treated as automatically more authoritative than the rest of the source article. The compiler must compare all relevant source blocks before it proposes a definition.
• Ambiguous exact terms means one canonical phrase or alias routes to several subjects. Correct the author guidance in Help Management.
• Unresolved issues groups compiler and validation findings by severity.
• Golden retrieval checks counts saved canonical terms and representative authored questions. The current question check verifies that retrieval reaches the expected Help source. It does not yet prove that every required fact was preserved, that the final answer is entailed by those facts, or that the answer wording is correct. Those checks require a richer golden-question contract and answer review.

Why an old page could show 0 / 172 while Azure showed 184 documents

The old 0 / 172 display meant that the active physical index could not be counted under the current retrieval contract. It did not prove that Azure contained zero documents. For example, an older physical index can still contain 184 records while a newly deployed application expects a v4 Answer Article projection and refuses to query the old schema. The two raw numbers are not expected to match across retrieval contracts.

The current page reports this as Rebuild required instead. Run Rebuild all to create a compatible projection. Do not delete the protected active physical index manually.

How to read the last operation

The result of the latest job is separate from the health of the current index:

• a failed rebuild can leave a previous healthy version working;
• a completed progress count such as 299 / 299 means the source work was processed, not that final validation and activation succeeded;
• Failed means Actualog stopped before activating unverified knowledge;
• the durable job ID, model, UTC times, internal phase, and original error are available under Technical job details for escalation.

What “Incompatible duplicate unit” means

Incompatible duplicate unit means that compilation produced two different claims for what appeared to be the same stable knowledge identity. Actualog stops the build instead of choosing one claim and silently publishing a potentially incorrect answer. The current working index is not replaced.

The identifier in the message, such as attribute-en-attribute-provider-attribute-definition, is an internal diagnostic key. It is not an Azure index and there is nothing with that name for an administrator to delete.

Take these steps:

1. Confirm that the application was restarted after the latest Help Knowledge compiler deployment.
2. If the failed job ran under an earlier compiler or retrieval contract, run Rebuild all again with the current compiler.
3. If the same duplicate appears in the new job, inspect the referenced Help Content for two contradictory definitions or lifecycle rules. Correct the authoritative Help, then retry.
4. If the sources are not contradictory, record the job ID and complete diagnostic key for a developer. Do not edit unrelated Help merely to remove the error.

The current compiler scopes provider-generated knowledge-unit identities to their exact HelpContentId + locale + source block evidence. This prevents different Attribute or Category articles that happen to use a local key such as definition from colliding. A true contradiction for the same evidence remains a blocking error by design.

Which command should I use?

Related administration pages

• Help Knowledge — build, update, monitor, and configure the Hex knowledge base.
• Help Management — create, edit, translate, import, and save the Help Content used as source evidence.
• Semantic Search — configure and test the shared embedding and Azure AI Search connections, and manage ordinary semantic entity indexes.

You must be an Application Administrator to use Help Knowledge. Editing individual Help topics can also require the Help Editor role.

What the page manages

Actualog exposes one logical Help Knowledge index. At rest, that logical index uses one physical Help Knowledge index in Azure AI Search and one current compiled knowledge graph in the Actualog SQL database.

The page therefore focuses on:

• the current index used by Hex;
• the last update or rebuild;
• read-only answer-quality diagnostics;
• read-only rebuild cost planning;
• compiler-model selection;
• the hard index-size budget;
• actual Azure AI Search usage.

The page does not present internal build copies as separate indexes.

Two reusable caches are stored separately from SQL snapshots:

• the source-embedding cache reuses unchanged vectors;
• the compiler-output cache reuses an unchanged, already validated compiler result when the source, prompt/schema contract, deployment, model contract, and navigation allowlist are all identical.

Removing an old snapshot does not remove cache entries that can safely be reused by a later build. Both caches are SQL application data; they are not additional Azure Search indexes or Azure resources.

What is a SQL snapshot?

A SQL snapshot is an internal working copy of processed Help stored in the Actualog database. It is not an Azure AI Search index.

It contains the exact Help revisions used by a build, knowledge subjects, source-backed claims, complete Answer Articles and their ordered membership, source references, application links, and validation results. Azure Search returns an Answer Article key; Hex uses the current SQL snapshot to hydrate the complete article and trace every claim back to source Help. A temporary snapshot lets Actualog finish and validate a build without changing the knowledge currently used by Hex.

The administrator does not manage these copies manually:

• after a successful operation, the new snapshot becomes current and obsolete snapshots are deleted automatically;
• after a failed or cancelled operation, its non-working snapshot is deleted automatically;
• the durable job keeps the final status and error message after its temporary snapshot is removed.

How articles become knowledge

An editorial Help document and an Answer Article are different things:

• a Help document is the source that an editor writes and users can read;
• a source-backed claim is one verified meaning, rule, step, warning, or result from that source;
• an Answer Article is the small, complete set of ordered claims that Hex needs for one kind of question.

The complete Help document remains stored as the original readable source; source-backed claims are not published as thousands of isolated search fragments. One Help document can produce several Answer Articles, and one Answer Article can combine compatible evidence from several Help documents. For example, the complete Answer Article for “What is Effective Template?” can combine its explicit Definition, the distinction from Category Template, and the relevant lifecycle rule even when those meanings occur in different source sections. It should not coexist with a second search document that contains only an isolated subsection fragment.

The pipeline:

1. parses headings, lists, callouts, paragraphs, and trusted page metadata into immutable source blocks;
2. forms bounded structural segments, keeping a heading with its local explanation, list, and example;
3. uses source embeddings to add a small overlapping context from semantically related segments, including segments from other Help documents;
4. asks the compiler to create typed, source-backed claims and complete Answer Articles;
5. combines equivalent evidence while retaining all sources and keeps conflicting meanings separate;
6. validates that every eligible claim belongs to at least one complete article.

The server, not the LLM, owns whether compiled Help is answerable. In this iteration compiled Help topics are answerable by Hex, while their Current, Preview, Planned, Historical, or Deprecated availability remains explicit so the answer can include the correct caveat.

The compiler model proposes the semantic structure; the server owns evidence integrity. The server removes unsupported links, normalizes safe structural mistakes, and, when the model omits a source block, adds an exact source-backed claim marked Requires review. This preserves the Help instead of silently losing it. A complete provider failure, timeout, unverifiable source reference, a claim that belongs to no article, or an incomplete article blocks the switch. A saved placeholder topic with no textual source blocks is retained in the captured catalog but does not create searchable knowledge.

The v4 search projection creates exactly one compact Azure Search document for each complete Answer Article. It does not mechanically split an article by characters, publish separate task/page copies, or attach unrelated claims just because they have a high similarity score. Search returns article keys; the complete ordered claims and evidence are hydrated from SQL. A broader free-form question can retain up to three score-compatible complete articles, so the answer model can combine several relevant concepts or tasks without receiving the whole Help corpus as noisy context.

The compiled definitions, facts, rules, and steps are a retrieval map, not a replacement for Help Content. When Hex composes the final answer, it receives the relevant original source blocks from up to three selected Help articles. It must compare those sources, support its answer with their source identifiers, and decline or clarify when the evidence is insufficient. This prevents a weak summary or an isolated subsection from becoming the answer merely because it was indexed first.

This resolves the apparent circular dependency: source segments can be embedded and related before the compiled knowledge base exists. Those embeddings improve the chance that related evidence meets in one compiler request; they do not decide what is true. Actualog indexes the compiled Answer Articles, not the original document boundaries or arbitrary fragments.

The two build commands

There are exactly two administrator build commands.

Update from Help changes

Use Update from Help changes after normal Help editing or import.

When the compiler, embedding, schema, and budget contracts are unchanged, Actualog:

1. compares saved Help Content with the current SQL snapshot;
2. expands the changed set through bounded semantic context and source dependencies;
3. recompiles only affected source-backed claims and Answer Articles;
4. reuses unchanged claims, articles, search documents, and cached vectors;
5. upserts or closes only affected Answer Article documents in the current physical index;
6. validates the new internal generation and makes it current automatically;
7. removes obsolete closed document versions and SQL snapshots automatically.

If nothing changed, the command completes without creating a new generation or calling the compiler. The command still checks that the configured embedding and search providers are available before it reports the no-change result.

Rebuild all

Use Rebuild all for:

• the first build;
• a compiler prompt or knowledge-schema change;
• deployment of retrieval v4 over an older index;
• an embedding model, vector-dimension, retrieval-schema, or other physical-index contract change;
• broad restructuring that cannot be bounded safely;
• recovery from index drift or damage.

The command is named Rebuild all, not “Create new index,” because the administrator is rebuilding the contents of the same logical Help Knowledge index.

Actualog compiles all configured Help Content and prepares all required retrieval vectors before the final Azure Search write. When service quota permits, the current index continues answering Hex while a replacement is built and checked. If every check succeeds, Actualog switches Hex to the replacement and automatically deletes the old physical index. A request that began immediately before the switch safely retries against the new active version if its old resources have already been retired. If the build fails or is cancelled before the final write boundary, Actualog keeps the current index and removes the unsuccessful working data.

On a small service where the complete old and replacement vector indexes cannot coexist, Actualog rechecks live quota at the final write boundary. It may delete only the exact current Help Knowledge physical index, create and probe the replacement, and activate it immediately. Hex Help answers are briefly unavailable during that controlled low-capacity cutover, and a late cancellation request is rejected once this boundary begins. The generic Semantic Search index is never deleted by this workflow. If the replacement fails after the deletion, the unsuccessful replacement is deleted too and Help Knowledge search remains unavailable until Rebuild all succeeds; the SQL runtime record is retained only for diagnostics. If the replacement cannot fit even after removing the current Help-only index, the rebuild stops before that deletion. At rest, only one current Help Knowledge physical index remains. This workflow never changes the Azure service tier, replicas, partitions, or other paid capacity.

Automatic workflow and failure safety

Both commands run as one durable background job:

1. Capture one consistent version of saved Help Content.
2. Parse the source and compile the required knowledge.
3. Store a temporary SQL working copy.
4. Validate evidence, identities, references, application links, complete claim coverage, complete Answer Articles, and compiler quality.
5. Create one compact retrieval document per Answer Article and enforce its document-count and estimated-size budget.
6. Prepare the current generation or a replacement physical index.
7. Verify document count, content hash, and queryability.
8. Confirm that saved Help Content did not change during the job.
9. Switch the current runtime automatically.
10. Remove obsolete SQL snapshots, closed document versions, and unused physical indexes.

A provider error, quota rejection, validation blocker, stale source catalog, or cancellation before the final write boundary leaves the current Hex runtime unchanged. In the low-capacity cutover, a failure after the current Help-only index is removed leaves Help retrieval unavailable until a successful retry; the unsuccessful replacement is still deleted automatically. On the first build, no Help Knowledge runtime becomes current until every step succeeds.

There are no separate Stage, Probe, Publish to Hex, rollback-storage, or candidate-cleanup commands. Verification and switching are internal phases of the selected build command.

Which model does what

Three model roles are separate:

• Knowledge compiler model — restructures source evidence into durable knowledge. Select an available compiler profile on Help Knowledge. A stronger model is normally appropriate because compilation affects later answers.
• Embedding model — finds semantic neighbors while building articles and creates retrieval vectors for complete Answer Articles. It improves recall but does not decide correctness, author knowledge, or guarantee the right answer.
• Grounded answer model — reads the selected original Help evidence and writes the user-facing Hex answer. Select its allowlisted profile independently on Help Knowledge. Changing this selection does not rebuild or enlarge the index; it affects subsequent answers.

The selected compiler profile, deployment, and model-name label are copied into the durable job when it is queued. The selected grounded-answer profile is stored independently and resolved only on the server. The Azure deployment determines the model that actually runs; the model-name label describes the configured contract. A profile's quality rank is an administrator-defined default-selection priority, not a measured quality score.

Increase a profile's model-cache epoch when an Azure deployment name is repointed to a materially different model revision without changing the deployment name. That deliberately invalidates old compiler-output cache entries. Normal Help edits, prompt/schema changes, model/deployment changes, or navigation-contract changes invalidate only the affected cache keys automatically.

A weaker compiler can require more exact source-preserving completion claims and produce more Requires review warnings. A stronger compiler should form better claims, terminology, semantic connections, and complete Answer Articles, but correctness and complete source coverage never depend on trusting the model without server validation.

The index budget is copied into the SQL snapshot when compilation starts. Provider endpoints, credentials, and API versions remain runtime configuration and are not copied into the snapshot, so do not change provider settings while a job is running. The activated runtime pins the exact SQL snapshot, physical index, generation, schema/version markers, vector dimensions, and content hash.

What is configured where

Application configuration

Deployment configuration defines:

• Ai:Conversation and Ai:Conversation:AzureOpenAi for the shared Azure OpenAI connection, authentication, and compatibility-fallback deployment;
• HelpKnowledgeCompiler for allowlisted compiler and grounded-answer profiles, Azure deployment names, model names, model-cache epoch, enabled state, quality rank, default profile, included locales, and optional InputPricePerMillionTokens, OutputPricePerMillionTokens, and PricingCurrency;
• baseline Ai:SemanticSearch settings.

Compiler and grounded-answer deployments reuse the server-owned Azure OpenAI connection and credentials. The browser submits only an allowlisted profile ID; it cannot submit an arbitrary endpoint, key, or deployment. The compiler and answer selections are independent even when they refer to the same allowlisted profile. Configuration-file changes normally require an application restart.

The two price fields are optional, but they must be configured together. PricingCurrency is an ISO 4217 currency code such as USD. These values let the page show an approximate compiler cost before a rebuild; they do not change provider billing and are not credentials.

If explicit profiles are not configured, Actualog exposes the shared conversation deployment as a compatibility fallback for both roles. This does not mean that the fallback model is the preferred compiler or answer model. Selecting a compiler profile applies to the build command you run; selecting a grounded-answer profile applies to later Hex answers. Neither selection rewrites the configured default profile.

Semantic Search

Use Semantic Search to configure and test runtime overrides for:

• the embedding endpoint, deployment, API version, version marker, and credentials;
• the Azure AI Search endpoint, index base name, API version, and credentials;
• the embedding model/version, vector dimensions, and retrieval settings.

The embedding deployment, model, the numeric Azure OpenAI embeddings → Embedding version marker, vector dimensions, and Help Knowledge retrieval schema form one contract. When that contract changes, update the embedding version marker and use Rebuild all. The general Azure Search core version, CoreTopK, and general minimum-score controls are not the Help Knowledge build identity or its fixed retrieval thresholds.

Changing only the Azure Search core index base name on the same service is supported: the old exact Help Knowledge index name is retained until automatic deletion succeeds. Changing the Azure Search endpoint moves the application to a different service; the application cannot delete an index left on the old service with the new service credentials. The successful rebuild job records the former physical index name. Remove that index through the old Azure service's administration tools.

The generic help entity on Semantic Search is the older article-level semantic index. It is not the compiled Help Knowledge index used by the current Help Knowledge runtime.

Help Knowledge

Use Help Knowledge to:

• select an allowlisted compiler profile;
• select an allowlisted grounded-answer profile without rebuilding the index;
• set the hard index budget;
• run Update from Help changes or Rebuild all;
• monitor the latest durable job;
• inspect the current logical index and actual Azure usage.

This page does not provision an Azure AI Search service, change its SKU, add replicas or partitions, or expose credentials.

Index budget and costs

The cost guard limits:

• maximum retrieval-document count;
• conservative estimated physical-index size;
• the stored Target passage characters planning value.

The code-owned free-tier preset allows at most 350 complete Answer Article documents, 20 MiB estimated index size, and a 12,000-character target passage. This keeps enough headroom in the current 50 MiB service quota for the active Help index, a temporary replacement during Rebuild all, and the existing non-Help index. Application Admin may save a different supported budget for future snapshots, but a larger limit does not add knowledge; it only permits more Answer Article documents and more Azure Search usage. Under retrieval v4, Target passage characters is retained as a compatible planning hint; it does not instruct the projector to split or merge a complete Answer Article. Article-risk and article-size diagnostics are the controls for semantic article quality. Each build freezes the saved policy in its SQL snapshot, so changing the setting affects the next build rather than rewriting a job that is already running.

The estimate includes retrieval text and metadata, raw vectors, vector-index overhead, and a safety margin. It is an Azure Search storage guard, not an Azure invoice. It is enforced before retrieval-vector generation and index writing, but only after source embeddings and compiler work have produced the knowledge graph. An over-budget build can therefore already have consumed Azure OpenAI tokens even though it does not grow Azure Search storage.

If complete eligible knowledge cannot fit within both hard limits, the build stops instead of silently omitting selected Help articles. Actualog never increases the Azure tier or adds capacity automatically.

A build can consume compiler-model tokens, embedding tokens for cache misses, and Azure AI Search indexing operations. Routine updates normally cost less because they reuse unchanged knowledge, validated compiler outputs, and vectors. The separate SQL compiler-output and embedding caches are retained across snapshot cleanup for that reuse; neither increases the Azure Search index size. Use Rebuild all only when its full replacement semantics are required.

Rebuild cost planning

Rebuild cost planning is read-only and does not call the compiler, embedding model, or Azure Search. It shows:

• approximate compiler source-input tokens;
• heading-aware compiler-call bounds for the normal semantic path and degraded fallback, plus per-call output-token caps;
• source-clustering embeddings and expected cache reuse;
• gross retrieval-embedding volume before reusable-vector cache hits and Answer Article characters;
• a normal-pass compiler cost envelope when the selected compiler profile has both token prices.

This is a planning envelope, not a provider quote. Compiler calls, source characters, and source-clustering cache hits are calculated from the current SQL Help catalog and the current embedding contract, even before the first build. The fixed system policy and strict output schema are included once per compiler call. The lower compiler value uses a four-characters-per-token planning ratio; the upper value uses a more conservative three-character ratio and applies the current input and output caps to every heading-aware structural call.

New Answer Articles do not exist until compilation. Retrieval-embedding volume therefore uses the active snapshot only as a clearly labelled baseline; before the first build it is shown as unavailable rather than as zero predicted usage. Exact provider tokenization, small JSON envelope overhead, repeated semantic context, cache billing rules, and final model behavior can differ. Transient failures can cause up to three attempts per compiler call. The compiler-cost figure also excludes embedding charges.

After real compiler calls, provider-reported input, cached-input, output, and total tokens are written to the application console log and stored with the reusable compiler-output entry. They are not currently aggregated as durable job totals, so the preflight page never presents its estimate as actual usage. A compiler-output cache hit makes no new model call; provider cached input tokens reported for a real call are the provider's own prompt-cache accounting and are not the same thing.

Help Knowledge reuses the existing configured Azure OpenAI and Azure AI Search services. It does not provision a new Azure resource, increase the Search tier, add replicas or partitions, or enable Azure telemetry.

For current Microsoft billing and quota rules, see Azure AI Search pricing and Azure AI Search service limits.

First build

Before an Application Administrator starts, the deployment operator must have applied the Help Knowledge migration and configured the server-owned Azure connections.

1. Configure at least one suitable compiler profile, or intentionally use the compatibility fallback.
2. Configure and test embedding and Azure AI Search on Semantic Search.
3. Import or edit and save the required topics through Help Management.
4. Open Help Knowledge.
5. Select the compiler profile for this command.
6. Confirm the hard budget and available Azure quota. If you apply the free-tier capacity preset, select Save index budget before building.
7. Select Rebuild all.
8. Monitor Last update or rebuild. The persisted job continues if you leave or refresh the page.
9. Confirm that Current Help Knowledge index is healthy.
10. Ask Hex representative definition and task questions and verify its Help and application-page links.

Update after Help editing

1. Edit, translate, or import the topic in Help Management.
2. Save the topic in the application database. Editing a Markdown file without importing it does not change the Help source catalog.
3. Open Help Knowledge.
4. Select Update from Help changes.
5. Monitor the last job and confirm that the current index remains healthy.
6. Test the affected questions in Hex.

If the page reports a compiler, embedding, schema, or budget-contract change, use Rebuild all.

Reading the page

• Current Help Knowledge index identifies the exact knowledge and physical index used by Hex.
• Last update or rebuild shows command, state, phase, model, progress, time, and final message.
• Answer quality diagnostics shows whether the active SQL graph can provide complete, source-backed Answer Articles for representative questions before answer generation.
• Rebuild cost planning estimates token and embedding volume without making an AI call.
• Models and index limits selects the compiler for the next build, selects the grounded-answer model for subsequent Hex answers, and stores the budget when you select Save index budget.
• Azure Search usage and physical storage shows service-wide quota counters plus per-index Help Knowledge storage.

Normally the managed-index table shows one protected current Help Knowledge index. A second protected row can appear temporarily while Rebuild all is running or automatic retirement is finishing when quota allows both indexes. Under a low-capacity cutover, the table can briefly show only the replacement while Hex Help retrieval is unavailable. An Unused and unprotected row is eligible for the explicit Delete unused index fallback; the server repeats all protection checks before deletion.

Common failures

• Help changed during the job — wait for the job to stop, then run Update from Help changes again.
• Compiler configuration, authentication, timeout, or complete fallback failure — correct application configuration, select a suitable compiler profile, restart when required, and start the appropriate command again. A complete conservative fallback is diagnostic only and cannot become current automatically.
• Source-preserving completion warnings — the build kept exact source evidence for blocks that the selected model did not structure reliably. The knowledge remains complete and can become current, but configure a stronger compiler profile and use Rebuild all when you want to improve the semantic graph.
• Embedding or search contract failure — correct and test settings on Semantic Search, then use Rebuild all.
• Azure quota failure — Rebuild all automatically uses the controlled low-capacity path when the complete replacement fits after removing only the current Help index. Otherwise reduce the future index budget or remove unrelated unused indexes; do not increase Azure capacity unless that is an explicit operational decision.
• Rate limit or temporary provider failure — wait for provider capacity to recover, then retry.
• Unexpected results after a successful build — correct the source Help or configuration and run the appropriate command again.

Record the durable job ID, command, phase, final message, and UTC time when escalating a failure. The failed SQL working copy and unsuccessful Azure replacement are removed automatically; the job retains the diagnostic result.

Expected result

After a successful operation, the page reports one healthy current Help Knowledge index. Hex first uses exact SQL terms, aliases, tasks, and page targets when available; otherwise it uses Azure hybrid lexical and embedding retrieval. It hydrates up to three complete, compatible Answer Articles rather than assembling an answer from random fragments. The grounded answer model then reads the selected original Help blocks, uses the compiled graph as a navigation aid, and returns only source-supported explanations, task guidance, trusted Help links, and authorized application navigation.