The NAVI AI Enablement Journey · Guide 03

Structuring a Knowledgebase

Four practical patterns for deciding what belongs, how people should find it, which hierarchy fits the work and how the system can remain dependable as the organization changes.

Core idea

There is no universally correct folder tree. Start with the questions people ask, the work they perform, the objects they manage, the systems that remain authoritative and the permissions that must be preserved.

Who this guide is for

Knowledge owners, implementation teams and business leaders organizing the governed information that people and NAVI should be able to rely on repeatedly.

When to use it

Use it when creating or improving a Knowledgebase, when retrieval feels unreliable, or before adding significant new sources, audiences or permission boundaries.

Decisions it helps make

Decide what belongs, which system remains authoritative, how information should be organized and who owns access, quality and continued maintenance.

How to continue

Use Guide 04 to establish the content lifecycle and Guide 05 when access, permitted use or human authority needs clearer governance.

Ask NAVI to apply this guide

“Use Guide 03 from the GrowthIQ Resource Library to review the knowledge relevant to our objective. Recommend the smallest maintainable structure, identify authoritative homes and owners, and explain what should remain in source systems or Workspace.”

Strong Knowledgebase candidates

Information that people and AI should be able to rely on repeatedly:

  • Approved policies and procedures
  • Product and service documentation
  • Operating standards
  • Training and onboarding
  • Approved templates and language
  • Troubleshooting guidance
  • Definitions and decision rules
  • Curated reusable examples

Content that usually belongs elsewhere

Working or sensitive information should not automatically become governed knowledge:

  • Early drafts and brainstorming
  • Personal notes
  • Temporary project material
  • One-time generated outputs
  • Raw system exports
  • Unreviewed transcripts
  • Duplicate source documents
  • Obsolete historical material

Six design
truths

Principles that apply regardless of industry or platform

1. Start with how people searchDepartment, task, product, project, property, machine, process or problem?
2. Use one main idea per levelMove secondary dimensions into metadata, filters, links or lower levels.
3. Standardize the contentA good location does not replace a clear policy, procedure or troubleshooting format.
4. Preserve one authoritative homeExpose the source through links and indexes rather than maintaining copies.
5. Consider permissions and applicabilityRole, location, product, customer, version and jurisdiction may factor into where content belongs and who can use it.
6. Make maintenance normal workOwners, review dates, feedback and retirement rules outperform annual cleanup.

Two layers make the Knowledgebase work

The visible organization is only one part of the architecture. NAVI also builds a retrieval layer behind the scenes.

System-generated by NAVIProcesses connected knowledge into search-ready content, preserves source context and creates retrieval indexes—including embeddings for semantic retrieval.
Defined by the organizationEstablishes authoritative sources, ownership, approvals, access, applicability, review and retirement decisions.

The combination is what makes the Knowledgebase powerful: strong organizational governance gives NAVI dependable knowledge to retrieve, while NAVI makes that knowledge substantially easier to find and use.

Four practical
architecture patterns

Select a front door, then adapt it to real questions and content

Pattern A

Company handbook

Primary question: Who owns this knowledge?
Company Knowledgebase ├── 00 Start Here and Governance ├── 01 Company Direction and Decisions ├── 02 People and Workplace ├── 03 Sales and Customer Growth ├── 04 Operations and Delivery ├── 05 Products and Services ├── 06 Finance, Legal and Administration ├── 07 Technology, Data and Security ├── 08 Approved Templates and Language └── 90 Historical and Superseded
Where it fits

Policies, employee operations, departmental standards and company reference material. Useful across manufacturing, services, nonprofit, healthcare and other organizations with defined functions.

Strengths
  • Familiar and easy to explain
  • Clear owners and permissions
  • Fast to establish
Watch-outs
  • Cross-functional work fragments
  • Users may not know the owner
  • Reorganizations affect the tree
Pattern B

Work and lifecycle

Primary question: What am I trying to accomplish?
How Work Gets Done ├── 00 Start Here and Governance ├── 01 Plan and Make Decisions ├── 02 Receive Requests or Generate Demand ├── 03 Qualify, Estimate and Approve ├── 04 Design, Schedule and Prepare ├── 05 Build, Deliver or Fulfill ├── 06 Inspect, Close and Document ├── 07 Support, Maintain and Resolve ├── 08 Improve, Renew or Expand ├── 09 Standards, Templates and Tools └── 90 Historical and Superseded
Where it fits

Construction delivery, manufacturing operations, professional services, customer lifecycles and any work where handoffs or automation matter.

Strengths
  • Matches user intent
  • Makes handoffs visible
  • Strong automation fit
Watch-outs
  • Ownership can be unclear
  • Documents support several stages
  • Process language must stay current
Pattern C

Product, service and support

Primary question: Which capability or problem do I need help with?
Product and Service Knowledge ├── 00 Start Here ├── 01 Getting Started ├── 02 Product or Service Families ├── 03 Common Workflows and Use Cases ├── 04 Administration and Configuration ├── 05 Integrations and Automation ├── 06 Security and Permissions ├── 07 Troubleshooting and Known Issues ├── 08 Release, Version and Compatibility ├── 09 Tutorials and Reference └── 90 Retired Products and Guidance
Where it fits

Software, equipment, building products, technical services, customer support and environments with versions, specifications or known issues.

Strengths
  • Natural for customers and support
  • Handles versions and compatibility
  • Strong self-service model
Watch-outs
  • Product trees become complex
  • Common procedures get copied
  • Applicability needs metadata
Pattern D

Industry objects, assets and projects

Primary question: What business object am I working with?
Operating Knowledgebase ├── 00 Start Here, Governance and Source Map ├── 01 Customers, Owners or Stakeholders ├── 02 Products, Assets or Equipment ├── 03 Projects, Jobs or Work Orders ├── 04 Sites, Facilities or Locations ├── 05 Suppliers, Vendors and Materials ├── 06 Operations and Maintenance ├── 07 Quality, Safety and Compliance ├── 08 Finance, Performance and Reporting ├── 09 Systems, Integrations and Data └── 90 Closed, Retired or Historical
Where it fits

Construction, manufacturing, real estate, logistics and other businesses organized around projects, assets, equipment, facilities or locations.

Strengths
  • Uses industry language
  • Supports operational systems
  • Strong vertical AI fit
Watch-outs
  • Objects live in several systems
  • Projects need access controls
  • Standards may be duplicated

Pattern comparison

PatternUsers primarily think byPrimary strengthMain risk
Company handbookFunction or ownerFamiliar structure and clear stewardshipCross-functional work becomes fragmented
Work and lifecycleTask, stage or desired outcomeStrong user intent, handoffs and automationOwnership and duplicate placement can be unclear
Product, service and supportProduct, capability or problemSupport, versions, reference and self-serviceProduct trees become complex and repetitive
Industry objects, assets and projectsBusiness object or operating entityHighly relevant to real industry workAuthority, permissions and duplication require discipline

Using a hybrid structure

A hybrid does not mean placing every possible dimension at the top. It selects the best primary structure for each domain while applying common governance.

Company Knowledgebase ├── 00 Start Here, Governance and Source Map ├── 01 Company Handbook │ ├── People and Workplace │ ├── Finance and Administration │ └── Technology and Security ├── 02 Customer and Delivery Lifecycle │ ├── Market and Sell │ ├── Contract and Onboard │ ├── Deliver and Support │ └── Expand and Renew ├── 03 Products, Services or Assets │ ├── Official Documentation │ ├── Procedures and Use Cases │ ├── Troubleshooting │ └── Versions and Known Issues ├── 04 Projects, Sites or Operating Objects ├── 05 Policies, Risk and Controls ├── 06 Approved Templates and Training └── 90 Historical and Superseded
One authoritative homeDo not maintain competing copies of the same rule or procedure.
One dimension at each levelKeep each branch understandable and predictable.
Secondary views through metadataUse role, stage, location, product, version and status without duplicating the source.

How to choose a starting structure

1. Collect real questionsGather ten to twenty recurring questions in the words users naturally use.
2. Inventory the answersIdentify the documents, systems and people currently used.
3. Test each patternPlace the questions and content; record ambiguous or duplicate placements.
4. Define authorityName the source, owner, access, review timing and conflict rule.
5. Build a pilot sliceStart with governance and two or three high-value domains.
6. Revise from useImprove based on searches, unanswered questions, stale content and permission issues.

Practical recommendation

Start with the simplest pattern that reflects how users already think. Then add the operating controls that make mature systems dependable: clear owners, one maintained source, repeatable content formats, applicability and permission information, links instead of copies, and a normal review and retirement process.