fix: resolve broken doc links and update concepts overview

Author: ravisuhag

docs/docs/concepts/overview.mdx

@@ -1,30 +1,32 @@
 # Overview
 
-Compass has three major concept when it comes to data ingestion: Asset, Type, and Service.
-
-Asset is the main model that represents a metadata of a specific service with a specific type.
-
-Type defines a ‘type’ of an asset and it is pre-defined. Compass currently supports the following types:
-1. `table`
-2. `job`
-3. `dashboard`
-4. `topic`
-5. `feature_table`
-6. `model` (under development)
-7. `application` (under development)
- 
-Service defines the application or source that maintains or generates the asset. Examples would be `biquery`, `postgres`, etc.
-
-Some features that compass has:
-* [Discovery](../tour/2-querying-assets.mdx)
-* [Lineage](../tour/3-asset-lineage.mdx)
-* [Asset Tagging](./asset#tagging-an-asset)
-* [User](./user.md)
-* [Discussion](../guides/discussion.md)
-* [Starring](../guides/starring.md)
-
-## Discussion
-Compass supports discussion feature. User could drop comments in each discussion. Currently, there are three types of discussions `issues`, `open ended`, and `question and answer`. Depending on the type, the discussion could have multiple possible states. In the current version, all types only have two states: `open` and `closed`. A newly created discussion will always be assign an `open` state. More detail about [Discussion](../guides/discussion.md).
-
-## Starring
-Compass allows a user to stars an asset. This bookmarking functionality is introduced to increase the speed of a user to get information. There is also an API to see which users star an asset (stargazers). More detail about [Starring](../guides/starring.md).
+Compass is an organizational context engine that builds a temporal entity graph of your systems and serves it to AI agents via MCP.
+
+## Core Concepts
+
+**Entity** is the core domain object — anything worth naming in your organization's knowledge graph: a table, service, pipeline, satellite, person, decision, etc. Entities have an open type system — any non-empty string is a valid type.
+
+**Edge** is a typed, directed, temporal relationship between two entities. Lineage, ownership, and other relationships are all modeled as edges.
+
+**Chunk** is a text fragment with a vector embedding for semantic search. Chunks are derived from entities — they're an indexing mechanism, not knowledge.
+
+## Features
+
+- **Entity Graph**: Temporal entities with typed edges and properties (JSONB)
+- **Search**: Keyword (tsvector), semantic (pgvector), and hybrid (RRF fusion)
+- **Context Assembly**: `get_context` builds a subgraph around any entity
+- **Impact Analysis**: `impact` traces downstream blast radius
+- **MCP Tools**: AI agents query the graph via MCP protocol
+- **Stars**: Users can star entities for quick access
+
+## Architecture
+
+All search is Postgres-native — no Elasticsearch dependency:
+
+| Mode | Engine | Purpose |
+|---|---|---|
+| Keyword | tsvector + pg_trgm | Exact matches, fuzzy/typo tolerance |
+| Semantic | pgvector cosine | Conceptual/natural language |
+| Hybrid | Both + RRF fusion | Best of both |
+
+Schema: `namespaces` → `users` → `entities` → `edges` → `chunks` → `stars`

docs/docs/configuration.md

@@ -269,9 +269,9 @@ client:
 
 #### Required Header/Metadata in API
 
-Compass has a concept of [User](./concepts/user.md). In the current version, all APIs in Compass require an identity header in the request. The header key is configurable but the default name is `Compass-User-UUID`.
+Compass has a concept of User. In the current version, all APIs in Compass require an identity header in the request. The header key is configurable but the default name is `Compass-User-UUID`.
 
-Compass APIs also expect an additional optional e-mail header. This is also configurable and the default name is `Compass-User-Email`. The purpose of having this optional e-mail header is described in the [User](./concepts/user.md) section.
+Compass APIs also expect an additional optional e-mail header. This is also configurable and the default name is `Compass-User-Email`. The purpose of having this optional e-mail header is described in the API reference.
 
 If everything goes ok, you should see something like this:
 

docs/docs/introduction.md

@@ -44,7 +44,7 @@ You can use the Compass command line interface to issue commands and to perform
 ### HTTPS API
 
 You can get hands on asset searching, listing, tagging, starring and much more by using the Compass HTTPS API, which lets you issue HTTPS requests directly to the service. When you use the HTTPS API, you must include the user information from the configurable identity uuid in the request header.
-For more information, see the [User Management](./concepts/user.md) and [API reference](./reference/api.md) pages.
+For more information, see the [API reference](./reference/api.md) page.
 
 ## Where to go from here
 

docs/docs/reference/configuration.md

@@ -60,15 +60,15 @@ Compass's required variables to start using it.
 ### `IDENTITY_UUID_HEADER`
 * Example value: `Compass-User-UUID`
 * Type: `required`
-* Header key to accept Compass User UUID. See [User](../concepts/user.md) for more information about the usage.
+* Header key to accept Compass User UUID. See the API reference for more information.
 ### `IDENTITY_EMAIL_HEADER`
 * Example value: `Compass-User-Email`
 * Type: `optional`
-* Header key to accept Compass User Email. See [User](../concepts/user.md) for more information about the usage.
+* Header key to accept Compass User Email. See the API reference for more information.
 ### `IDENTITY_PROVIDER_DEFAULT_NAME`
 * Example value: `shield`
 * Type: `optional`
-* Default value of user provider. See [User](../concepts/user.md) for more information about the usage.
+* Default value of user provider. See the API reference for more information.
 
 ## Telemetry