sharkasm
← Back to the portfolio

OPERATIONAL KNOWLEDGE

VectorOne

Find the evidence behind the answer.

A telecom and NOC knowledge retrieval service that turns operational documents and source records into cited evidence for people and agents.

COMPLETED · IN USE5 MIN READ08 CHAPTERS
  1. 01Ingest
  2. 02Embed
  3. 03Search
  4. 04Return evidence
In this story ↓

AT A GLANCE

  • Ingest source content, normalize metadata, chunk documents, and generate embeddings.
  • Store vectors and metadata with PostgreSQL and pgvector, with optional Vertex and BigQuery vector backends.
  • Return retrieval evidence and citations over REST and MCP.
  • Keep knowledge retrieval as a dedicated service that can feed an agent or an operator-facing application.
PostgreSQLpgvectorRESTMCPSource citations

01 / 08

Retrieval built around operational evidence

VectorOne is a telecom and NOC knowledge retrieval service. It ingests supported operational documents and source records, prepares the text and metadata, creates embeddings, stores vectors, and returns evidence with citations. It does not generate the final LLM prose itself. That focused responsibility gives the portfolio a reusable knowledge capability for both operator-facing tools and AI agents.

The design separates two questions: which source material is relevant, and what a consuming application should say or do with it. VectorOne addresses the first question. The resulting evidence can then support a human investigation or an agent workflow while preserving a path back to the source material used in the retrieval.

02 / 08

Connect multiple source types

The documented connectors include files, REST, BigQuery, Iceberg, Kafka, and Pub/Sub. They implement a common pulling and acknowledgement contract while respecting the differences between source types. A streaming source may need its acknowledgement deferred until processing succeeds, while a file or query-based source has a different synchronization pattern.

This shared contract helps ingestion deal with source identity and progress consistently. A pulled record carries the text and metadata needed for processing, plus acknowledgement context where relevant. The connector layer currently expects text records. Content preparation for richer binary formats is a separate responsibility, so source onboarding should establish how the intended material will arrive in a representation the implemented pipeline can process.

03 / 08

Prepare content for retrieval

The ingestion pipeline normalizes and enriches metadata, chunks the source text, generates embeddings, and stores the resulting vectors with their metadata. These steps connect the source record to the units a retrieval request can return. Chunking determines how the source is divided into useful passages, while metadata preserves context about those passages.

That context is essential in an operational setting. A retrieved fragment should be understandable as part of a document or source record, not as an isolated sentence without provenance. The pipeline’s purpose is therefore broader than storing a numeric representation. It prepares information so that the retrieval result can be examined and connected to the source from which it came.

04 / 08

Keep synchronization state meaningful

VectorOne’s source synchronization calls the connector, processes returned records, and acknowledges inserted or duplicate records under the documented behavior. Cursor advancement occurs when the batch succeeds. Kafka and Pub/Sub connectors retain their own acknowledgement information so that message acknowledgement can follow ingestion rather than precede it.

These details support an operationally understandable ingestion process. If a source is behind or a batch fails, the team needs to reason about which records were accepted and where processing should continue. The source cursor and acknowledgement behavior provide part of that account. The result is a clearer link between source progress and the knowledge available to retrieval consumers.

05 / 08

Store vectors with their context

The primary stack uses PostgreSQL and pgvector, with optional Vertex Vector Search and BigQuery vector-search backends. The service keeps vector retrieval connected to metadata and source identity. This allows the returned evidence to carry more than a similarity result: it can preserve the context needed to interpret the relevant passage.

The important product boundary remains the retrieval service. Consumers should be able to ask for evidence through the service interface while the storage and search implementation stays behind that boundary. This makes the capability easier to integrate into different operational experiences without requiring every client to manage its own vector infrastructure.

06 / 08

Expose evidence through REST and MCP

REST provides an application interface for retrieval, while MCP makes the capability available to agent clients. A web application can display results directly to an operator; an agent can retrieve evidence as a tool call before composing a response. Both paths benefit from a common retrieval responsibility and consistent source context.

This division also makes it easier to inspect an AI-assisted answer. The retrieved evidence exists independently of the generated prose, so the user can examine whether it supports the interpretation being offered. The architecture does not ask the retrieval service to become the entire assistant. It gives assistants and applications a focused source of operational knowledge they can incorporate into their own workflows.

07 / 08

Use citations as part of the experience

A citation is useful when it leads the reader back to the supporting material. In a telecom investigation, an answer may need to be compared with current network conditions or discussed with another specialist. Source references make that examination possible and help distinguish a relevant historical note from evidence that directly applies to the current situation.

VectorOne’s emphasis on cited retrieval supports that experience. The consumer receives information that can be traced to its origin, and the person using it can judge its relevance. This is particularly important for operational knowledge, where a technically similar passage may describe a different environment, service state, or time. The citation gives the user a route to inspect those differences.

08 / 08

An illustrative knowledge-retrieval workflow

An engineer or agent submits a question related to an operational issue. VectorOne searches the prepared knowledge and returns relevant evidence with source references. The client presents those results or uses them as context for its next step. The engineer can then examine the cited material and decide whether it fits the current investigation.

The workflow connects several portfolio themes: data democratization makes information easier to access; PyBrain can use retrieval through tools; observability helps inspect the application behavior; source systems retain their own operational responsibilities. VectorOne supplies the evidence-retrieval layer among them. Its contribution is a reusable, inspectable way to bring operational knowledge into the point where a person or application needs to make sense of a technical question.

LET’S MAKE THE CONNECTION

Put this experience
to work.

Bring your requirements, your operating context, and the question you want to answer.

Discuss VectorOne ↗