Built Like Enterprise Infrastructure

Enterprise memory infrastructure needs controls that operators can inspect and administer. GoodMem combines a typed Java 21 server, PostgreSQL persistence, resource-aware access control, and a verified delivery pipeline. Human users and service identities can share memory under explicit permissions, while scoped API keys limit what each credential can do. PAIR Systems is ISO 27001 certified; its SOC 2 Type II audit is in progress.

A familiar operational foundation

GoodMem runs as a Java 21 service and keeps core application data in PostgreSQL: memories, extracted text, dense and sparse embeddings via pgvector, requested page images, authorization records, background jobs, and retrieval logs. Operators can inspect these records with SQL and use their existing database backup and access practices. Core persistence needs no separate vector database or message broker.

Deployment configuration and TLS key material also need appropriate backup and protection. Keeping application data in PostgreSQL makes its storage familiar and portable; encryption at rest and backup retention remain deployment responsibilities.

Access control for people and workloads

GoodMem includes instance-level ADMIN and USER roles and a space-level role ladder: viewer, contributor, content manager, and administrator. Direct grants can authorize specific resources or supported groups of resources. Access-policy administration, ownership transfer, and authorization checks are available through the APIs and console. The server enforces policy for the requested operation and resource, including filtering visible collections in PostgreSQL.

Human users and service identities have separate lifecycles. One-time enrollment credentials support human onboarding, while workload identity stays independent of any individual API key. Scoped keys are bounded by an immutable issuance ceiling intersected with the subject’s live permissions; service-identity keys must be scoped. Issuance checks prevent a credential from granting authority beyond its issuer or subject.

Model use is also separate from secret disclosure: reading or executing a provider resource does not automatically authorize reading its credentials. Built-in roles are code-defined, and access partitions within one instance are not hard tenant boundaries; supported tenant isolation uses separate databases.

A verifiable software supply chain

The GoodMem server image runs non-root on a distroless Java 21 base without a shell or package manager. The normal installer verifies signed SLSA Build Level 3 provenance and checks the pulled image against its attested digest. Verification can be explicitly disabled by the operator. Before publication, the release workflow verifies installation and upgrade with the newly signed artifacts, as well as CLI provenance. Offline CLI upgrades can verify a supplied local provenance bundle.

Release dependencies include blocking OSV vulnerability checks and FOSSA license-policy checks, with third-party attribution material published alongside the release. Server and CLI security pipelines generate SBOMs. Grype adds a separate reporting scan. Dependency scanning honors documented exclusions, so these controls are not a promise that every release has zero unresolved CVEs.

The server uses Bouncy Castle FIPS providers with approved-only mode enabled by default. The standard build’s BC-FJA 2.1.2 module is not currently validated; the normal CLI and database are outside that server cryptographic boundary. Consult the FIPS documentation for the exact deployment scope.

Treat retrieved material as data

Permission to contribute memory does not make the contributor’s text trusted instructions. GoodMem’s synthesis path applies a mandatory policy and request-specific delimiters around retrieved records. Hosted MCP responses label contributor-controlled content as untrusted and carry source provenance; generated answers are identified as model output derived from those sources. These controls help consumers preserve the distinction between evidence and instructions.

Extension handling has an administrative boundary too: the built-in USER role has no extension-management authority, and plugin loading selects active JAR extensions. These controls reduce exposure; they do not guarantee that arbitrary plugins or model responses are safe.

Operate, observe, and integrate

GoodMem exposes native Prometheus metrics for the JVM, HTTP, gRPC, and PostgreSQL, with liveness, readiness, and startup probes plus standard gRPC health checks. Lifecycle controls support graceful draining. Database startup retries transient connection failures with bounded backoff; migrations run outside that retry loop.

Request IDs correlate the REST-to-gRPC resource API. Retrieval requests can be persisted through caller opt-in or administrator logging policies, including request, outcome, and provenance information. This logging is asynchronous and best-effort; it is not an exhaustive audit of all API operations.

Document processing includes configurable OOXML extraction limits and bounded XLSX page-image rendering. Page images are generated when requested for supported inputs and expose processing status. TLS supports customer certificates, development self-signed certificates, and native ACME issuance, renewal, and reload.

Integration uses protobuf-defined gRPC, REST with a live OpenAPI specification, and a built-in MCP server. Maintained clients cover Python, Java, TypeScript, Go, and .NET.

Preserve memory while choosing your models

GoodMem’s standard indexing path extracts, chunks, embeds, and indexes source content without requiring a generative memory-extraction step. Retrieval combines vector search with optional reranking and optional synthesis. Original content and extracted text remain stored alongside the index, with page images available when requested.

Embeddings support OpenAI, Cohere, Jina, Voyage, DashScope, Gemini Embedding 2, TEI, and vLLM. Gemini execution currently supports text inputs. Reranking supports Cohere, Jina, Voyage, DashScope, TEI, vLLM, and llama.cpp. Optional synthesis supports OpenAI-compatible endpoints, OpenRouter, LiteLLM, DashScope, vLLM, Ollama, and llama.cpp.

An agent or summarization-model change does not inherently require rebuilding the memory corpus. An embedding-model change is different: in-use embedder core fields and a space’s embedder associations are protected from modification. Moving to a different embedding model requires rebuilding embeddings through an appropriate re-ingestion workflow; automatic migration is not implied.

A deployment can keep AI processing inside its own boundary by using self-hosted model endpoints and configuring any OCR endpoint it uses accordingly. Local processing is an explicit deployment choice, not an assumption about default endpoints.

Security and supply chain, side by side

Green: confirmed control. Amber: absent or limited in the reviewed scope. Gray: neutral, not applicable, or unverified.