Sense AI · Knowledge systems and copilots

Make enterprise knowledge answerable without hiding authority, access, or uncertainty.

We engineer permission-aware retrieval, citation, correction, and corpus operations for service, policy, engineering, and case knowledge. The output is a governed publishing and access service, not a one-time vector index.

Design a knowledge service Inspect the retrieval path

Sources: Authority, audience, access, freshness, supersession, deletion, and conflict policy
Retrieval: Identity filters, metadata, candidate selection, context assembly, citation
Operations: Ingestion ownership, quality review, access-change tests, correction, incidents

01 · Information contract

Retrieval cannot repair contradictory sources or absent ownership.

We map source authority before ingestion so ranking behavior does not silently become policy.

Authority and audience

Name source owners, intended users, binding status, supersession rules, and conflict treatment.

Access and deletion

Propagate identity and group access, removal, legal hold, and retention through every derived representation.

Freshness and correction

Define update expectations, failed-ingestion handling, correction routes, and visibility of stale material.

02 · Retrieval path

Ingestion, indexing, retrieval, ranking, and context assembly need separate contracts.

The design can use Azure AI Search classic or agentic retrieval where appropriate, but source and access policy remain explicit application concerns.

Ingest

Extract content and metadata, preserve source identity, record version, and quarantine malformed input.

Filter

Apply user and group access, tenant, source, freshness, jurisdiction, and intended-use constraints.

Retrieve

Generate candidates, rerank, expose score and trace, and retain conflict or insufficiency signals.

Compose

Build bounded context, require citations, distinguish sourced claim from synthesis, and abstain when unsupported.

03 · Quality contract

A fluent answer can still retrieve the wrong evidence or violate an access boundary.

Representative cases segment ordinary, sparse, conflicting, stale, denied, and unanswerable conditions.

Retrieval

Relevant-source recall, irrelevant context, correct access filtering, and conflict representation.

Case-level retrieval trace

Support

Claim support, citation resolution, source fidelity, and separation of synthesis from sourced fact.

Reviewer rubric and claim findings

Behavior

Usefulness, clarification, correct abstention, correction path, and escalation under uncertainty.

Acceptance threshold by case class

04 · Technical view

Users and operators need a path from claim back to source and access decision.

The interface should show citations, source freshness, conflicts, and correction routes without exposing internal implementation details.

Illustrative reference patternSource authority and retrieval

Published policyAuthority: primary

Service recordsAuthority: operational

Working guidanceAuthority: advisory

Identity filterFreshnessConflict rule

Supported answer

Claims remain connected to source, version, access decision, and retrieval trace.

3 claims supported

1 conflict disclosed

Illustrative pattern. A supported answer retains the source version, permission decision, retrieval trace, and any unresolved conflict.

Source owner

Authority and maintenance responsibility remain visible outside the model configuration.

Permission evidence

The system can explain which access rule admitted or denied a source for the requesting identity.

Answer proof

Claims, citations, conflicts, and abstention remain reviewable at the case level.

05 · Engagement contract

A knowledge service changes whenever its sources, permissions, users, or task change.

Handover establishes source-owner duties, ingestion and access tests, reviewer cadence, incident routes, and controlled retrieval changes.

Source registry

Authority, owner, access, update, retention, conflict, and deletion contract per source.

Evaluation pack

Representative cases, retrieval and answer rubrics, thresholds, and known limitation register.

Operating pack

Ingestion, access-change, correction, quality, incident, release, and rollback runbooks.

Engagement contract

What must be true, who owns what, and what leaves the engagement.

A good fit when

Support, policy, engineering, or service teams searching fragmented knowledge
Copilots that must respect document permissions
Existing RAG pilots with citation, freshness, or quality problems

Required before delivery

Named source and access-policy owners
Representative questions, users, and denied-access cases
A supported identity route and approved hosting foundation

Customer owns

Approve source authority and conflict rules
Provide access groups, retention, and deletion policy
Supply accountable domain reviewers and acceptance thresholds

Delivery outputs

Source and retrieval architecture
Permission-aware knowledge service
Evaluation, correction, ingestion, and operating pack

Not included by default

Azure tenant, network, identity, Foundry, Search, monitoring, or platform foundation unless Sense Cloud is included in scope
A production guarantee based on a prototype or vendor benchmark
Unrestricted autonomous action or implicit approval authority
Customer policy, source ownership, or risk acceptance decisions
Automatic truth arbitration when authoritative sources conflict

Questions to answer first

Which source is authoritative when two answers disagree?
Can permission removal reach every index and cache?
What should the system do when support is insufficient?

The next step is a bounded working session: one workflow, its evidence sources, the decision owner, and the conditions under which the system must stop or hand over.

Design a knowledge service