ProtoMolt

The ProtoMolt ecosystem

Bring your gRPC
services together.

Map and project data between service contracts, apply validation, and compose calls into reusable workflows. Connect services that use different message shapes, then make that work accessible to applications and agents.

Find your starting point Read the overview

A protobuf/gRPC ecosystem for service integration, schema management, document storage, and search. Use the pieces you need.

Explore the architecture

Contracts connect the work.

Choose a part of the map to see how it works.

Shared protobuf contract Data + declarations Types, validation rules, projections, indexing hints, and metadata. Explore the foundation

Validate

Check records against field rules and CEL expressions at runtime.

Explore validation

Map and project

Select and reshape one service’s output to match another’s input.

Explore transformations

Connect

Bring Kafka records and gRPC services into the same flow.

Explore connectors

Store

Keep bytes in S3-compatible storage and a Postgres ledger. Retrieve complete documents or selected parts.

Explore the repository

Search

Declare index fields, chunking, and embedding settings on the schema.

Explore indexing and search

Run workflows

Run and track work across services, synchronously or as durable jobs.

Explore execution

Declarations describe the rules. Configured libraries and services execute the ones they support. Connections, credentials, and deployment choices stay in your configuration.

A concrete example

Use AI to build the integration.
Run the integration as software.

An illustrative developer workflow using ProtoMolt tools.

  1. Inspect

    Service A + service B

    An agent reads both services’ contracts to understand their inputs and outputs.

    How it works

    Register reachable gRPC services with reflection enabled. Inspect their message shapes and the supported operations exposed as tools by the configured host.

    Service discovery and tools

  2. Map and project

    A’s output → B’s input

    Select fields, reshape records, and apply the target contract’s rules.

    How it works

    For example, map A’s customer_name into B’s display_name. Use ProtoMolt’s mapping and projection tools to select paths, apply expressions, and fill defaults where the integration needs them.

    Mappings and projections

  3. Check and refine

    Fixtures → expected results

    The agent exercises exposed operations through MCP and checks the composed result.

    How it works

    Use fixtures with explicit expected values: customer_name “Ada” should produce display_name “Ada”. Check those mapped values as well as declared validation rules, test rejected inputs, and revise the mapping when results differ.

    Runtime validation

  4. Deliver

    Tested wiring → software

    Keep the composition as a reusable workflow or a gRPC integration application.

    How it works

    A developer can use the tested mappings and service calls in an ordinary application, or save a supported executable workflow. Deliver the contracts, fixtures, and test evidence with it.

    Reusable workflow guide

The agent helps build and test the connection. The delivered integration runs its saved mappings and calls without asking a model to reconstruct the wiring for each request.

Then index and deliver the results.

Once the mapped results meet your expectations, feed them into a supported search index and deliver them to downstream systems through connectors and output adapters. Indexing and delivery are separate consumers of the same prepared data.

Start with a useful piece

Bring the problem you already have.

Keep schemas and rules together

Version protobuf definitions in the registry and use them with runtime validation.

Schema registry

Make two systems agree

Map fields and project records into the shape a downstream service expects.

Mappings and projections

Put documents to work

Parse source documents into shared typed records, then connect storage and indexing.

Document processing

Prefer to start in code? Browse the reusable libraries or follow a getting-started guide.

Agents can use these contracts too, through MCP and ACP interfaces and validated result contracts.

A closer look · executed example

See what one definition can do.

A filing service calls its title style_of_cause. A search document calls it title. This small, real run connects the two, checks the rules, and turns that title into a vector for search.

Source service

CaseSource.Read

case_id
24-cv-00117
style_of_cause
State v. Example

A synthetic filing from ProtoMolt’s projection test fixture.

court-search.proto

SearchDoc

The target shape carries the instructions.

  • Title must have at least 2 characters
  • style_of_cause → title
  • Text index + 384-dimensional vector
  • Documented requests and responses
Projected record

DocumentSink.Accept

doc_id
24-cv-00117
title
State v. Example

Validated and accepted over gRPC.

Validate

Declared on title

required: true
string: { min_len: 2 }

The same runtime validator checks the projected record and the destination RPC’s input.

Observed rejection

title: "X"

INVALID_ARGUMENT

length must be at least 2. The valid title, “State v. Example”, passes.

Project

Declared on the target field

string title = 2 [
  (ai.protomolt.proto.projection.v1.from) = {
    paths: { path: "style_of_cause" }
  }
];

The target also declares Case as its source type. This field projection selects its value without changing the source service.

Actual MessageProjection output

{
  "doc_id": "24-cv-00117",
  "title": "State v. Example"
}

Both values were checked against explicit expected results.

Index and embed

Embedding policy from the definition

embedding: {
  model: "sentence-transformers/all-MiniLM-L6-v2"
  dims: 384 similarity: VECTOR_SIMILARITY_COSINE
  normalize: true
}
vector_field: "title_vector"

The index-hint reader resolves doc_id as a keyword and title as text. The declared sentence-packing policy produces one chunk here.

Real model output

384 coordinates, one title

Input: “State v. Example”

TEI 1.9.3 ran MiniLM in float16. ProtoMolt applied the declared L2 normalization; the measured L2 norm is 0.99999998.

Cosine similarity is the declared search metric. The dimensions do not have individual human-readable meanings.

All 384 coordinates, in order. Blue is positive; brown is negative. Darker means a larger absolute value.

First 8 of 384 coordinates, rounded to 6 decimals

[-0.058958, 0.054525, 0.001623, 0.024416, -0.008081, 0.076472, -0.028181, -0.026488, …]
Inspect the full vector and recorded results →

Connect services

Service declarations

// Read one sample filing by its source identifier.
service CaseSource {
  rpc Read(CaseKey) returns (Case);
}
service DocumentSink {
  rpc Accept(SearchDoc) returns (Receipt);
}

The definition documents each shape and its purpose in protobuf comments. Those comments are retained in the compiled descriptor set.

Executed service calls

Read → project → validate → accept

{
  "doc_id": "24-cv-00117"
}

Both sample services ran over loopback gRPC. A separate, already-running TEI gRPC service produced the embedding.

Read the complete, compiled protobuf definition 
syntax = "proto3";
package website.court.v1;
option java_package = "demo";
option java_outer_classname = "CourtTypes";

import "ai/protomolt/proto/projection/v1/projection.proto";
import "ai/protomolt/proto/validate/v1/validate.proto";
import "ai/protomolt/proto/index/hints/v1/indexing_hints.proto";

// Source service: a filing system uses its own field names.
service CaseSource {
  // Read one sample filing by its source identifier.
  rpc Read(CaseKey) returns (Case);
}
message CaseKey { string case_id = 1; }
message Case {
  string case_id = 1;
  string style_of_cause = 2;
}

// Destination service: accept the projected, validated search document.
// This demo acknowledges a document; it does not persist a search index.
service DocumentSink {
  rpc Accept(SearchDoc) returns (Receipt);
}
message Receipt { string doc_id = 1; }

// Common search shape, adapted from ProtoMolt's court projection fixture.
message SearchDoc {
  option (ai.protomolt.proto.projection.v1.sources) = {
    source: "website.court.v1.Case"
  };
  // Preserve the filing identity as an exact-match search key.
  string doc_id = 1 [
    (ai.protomolt.proto.projection.v1.from) = { paths: { path: "case_id" } },
    (ai.protomolt.proto.validate.v1.field) = { required: true string: { min_len: 1 } },
    (ai.protomolt.proto.index.hints.v1.index) = { type: INDEX_FIELD_TYPE_KEYWORD }
  ];
  // Project the case name into searchable text and derive a title vector.
  string title = 2 [
    (ai.protomolt.proto.projection.v1.from) = { paths: { path: "style_of_cause" } },
    (ai.protomolt.proto.validate.v1.field) = { required: true string: { min_len: 2 } },
    (ai.protomolt.proto.index.hints.v1.index) = {
      type: INDEX_FIELD_TYPE_TEXT
      chunking_policy: {
        chunking: {
          strategy: "sentence-packed" strategy_version: 1
          target_tokens: 128 overlap_tokens: 0 min_tokens: 0 max_tokens: 128
          boundary: "rules-v1"
        }
        embedding: {
          model: "sentence-transformers/all-MiniLM-L6-v2"
          dims: 384 similarity: VECTOR_SIMILARITY_COSINE normalize: true
        }
        vector_field: "title_vector"
        store_chunk_text: true
      }
    }
  ];
}

Download the definition

Inspect the run and reproduce it

This sample combines the checked court projection fixture with ProtoMolt’s validation and indexing annotations. The standalone Java program compiles the definition, serves the two RPCs, projects and validates the record, reads its search policy, and runs PolicyDerivation against a real embedding server.

Model: sentence-transformers/all-MiniLM-L6-v2. Cached model revision: 1110a243fdf4706b3f48f1d95db1a4f5529b4d41. The provenance file records the model weights’ SHA256 and runtime artifact hashes. Floating-point output can vary slightly by hardware and runtime.

Reproduction instructionsExecuted Java sourceRun scriptProvenanceFull output

Recorded 2026-10-02. Projection, valid and invalid requests, gRPC calls, chunking, and model inference were executed. The destination acknowledged the document; this run did not write a persistent search index. Endpoints and deployment remain runtime configuration.