Writes are proposals
An observation proposes a change. Consolidation decides what becomes current and reports applied, skipped, refused, or held updates. Schema changes follow a proposal path too.
Our principles
Your agents need to know what the database currently accepts and how it got there. These seven principles guide how ConceptMem handles proposed updates, shared models, policy, and provenance.
Built into the workflow
An observation proposes a change. Consolidation decides what becomes current and reports applied, skipped, refused, or held updates. Schema changes follow a proposal path too.
Reconcile incoming information with existing facts. Repeated values leave the fact unchanged; conflicting values follow your policy. Keep a current record and the history of its changes.
Read accepted facts for the next action. Query earlier values, validity periods, and the changelog when you need to explain what changed and when.
Share a model of entity types, fields, and relationships. Choose open or strict classes, or enforce one field’s type and allowed values. Stronger constraints are an explicit choice.
Record the source, actor, confidence, timestamp, and extraction method behind mutations. Make the origin of a change available to the people and agents who need to inspect it.
Generate Markdown pages, summaries, and exports from stored state. Submit a new observation to correct the record; edits to a derived view do not mutate the database.
Configure update, conflict, and review rules with class defaults and field overrides. Retention and privacy settings can be stored and reported, but their enforcement is not implemented.
Connect through hosted REST or MCP, or explore the TypeScript SDK preview. Ontology validation, consolidation, and policy run inside the managed service for every submitted observation.
Explore the integrationsInformation can be late, duplicated, incomplete, or conflicting. Consolidation checks each proposal against the model, current state, and policy. The caller sees what was applied, skipped, or held, along with violations, and can act on that result.
Current-state queries read accepted facts directly. Earlier values stay available separately, with the periods when they were recorded as valid. This lets an agent answer a current question and investigate an earlier value without mixing the two.
Open classes accept undeclared fields and report type, allowed-value, and relationship mismatches without blocking unless a field is enforced. Strict classes refuse those writes. An enforced field can reject an invalid type or value on an open class. Missing required fields are advisory in both modes.
Schema changes go through a proposal service that validates the complete candidate schema before applying it. An expected revision can guard against a stale change, and applied changes are audited. Templates are adopted explicitly. Agent permission to change schema depends on the instance’s governance settings; human administration requires authenticated user access.
Source, actor, confidence, timestamp, and extraction method make each mutation inspectable and support conflict decisions and review. They document the evidence behind a recorded fact. The quality of that fact still depends on the observations and policies you provide.
Markdown pages, summaries, and exports are generated from the database. Editing one does not mutate stored state. A correction goes back through the proposal path, where the same ontology, policy, and provenance requirements apply.
Inside the managed ConceptMem service. Clients submit observations and schema proposals through hosted REST or MCP; the TypeScript SDK is in preview. The service validates and applies proposals according to the caller’s authority and workspace rules.
Start with one shared record
Create a database on the free plan, connect an agent over MCP or REST, and propose your first update.