Separation between businesses
In developmentEach business's records are tagged to its organization, and database access rules limit staff to their own organization's data; known gaps in this separation are still being closed.
Lamiak Core · Deployment and governance
Where your records sit, and what governs a change.
How records are kept apart per organisation, which outside services receive data and why, and what would have to be true before something changes.
The question
Where does our data sit, and who decides what changes?
Records are tagged to the organisation they belong to, and database access rules are set up per organisation. Known gaps in that separation are open work, and we hold the status at in development until they are closed. Outside services are called for a named purpose, and which ones receive a product's data is published before that product is offered to customers. What would govern a change — a registry of what is running, and a gate a candidate has to pass — is designed and not built.
How it works today
In developmentWhat is built, stated as built.
Separation between organisations is built and still being hardened. What crosses the boundary is a short, named list.
Tagged to an organisation
Every record carries the organisation it belongs to, and database access rules limit staff to their own organisation's data.
Gaps held open
Known gaps in that separation are open work. The registry entry stays at in development until they are closed, rather than being raised early.
Outside services are named
Model, transcription, payment, messaging and calendar services are called for a named purpose, and which ones receive a product's data is something we will publish before that product reaches customers.
What is planned
PlannedWhat is designed, stated as designed.
The machinery that would govern a change is on the registry as planned.
A record of what is running
Models, adapters and prompts listed with the evaluation history behind each one, so a question about a result has somewhere to go.
A gate before authority
A candidate would have to do better on evaluations before it is trusted with more in production than the one it replaces.
Where the records sit
One boundary, with named crossings.
Inside your organisation's boundary
- Client and job records
- Documents and messages
- Workflows and approval rules
- Feedback and outcomes from your work
Outside the boundary
- Model and transcription providers, called for a specific task
- Payment, email, text-message and calendar services you connect
What this leans on
The registry entries behind this page.
Each card carries its own status, taken from the registry rather than written here. How the labels are used is set out on the trust page.
Model registry
PlannedA registry of models, adapters and prompts with their evaluation history.
Model promotion gates
PlannedA candidate must prove better on evaluations before it receives authority in production.
The rest of Lamiak Core
The parts this one sits beside.
- ContextWhat the system knows before it acts.Assembling the records, documents and permissions a task needs into one packet, before an agent is allowed to do anything with them.
- AgentsAgents that propose, inside limits you set.Bounded agents that draft and propose rather than act, with each step sent to a model or to plain code depending on what the step is.
- Workflows and approvalsSteps that run the same way, and the person who decides.Ordinary repeatable steps, with a person approving where the policy for that workflow says so, and each decision recorded with who made it and when.
- Evaluation and learningMeasure first, then decide what changes.Evaluation suites and graders run by hand today. Scorecards, promotion gates, dataset snapshots and training from outcomes are designed and not built.
Start with one workflow that matters.
We map the work, the systems it touches and the approvals it needs before anything is automated.