2027 · MerTek technology
Engineering reference / System overview
Deny-by-default checks at every boundary
Every request in an MTK deployment crosses five boundaries: identity, application, tenant and data, service, and device. Each boundary starts from denial and admits only what a declared grant names. A request stops at the first boundary that refuses, and the refusal names that boundary.
Worked example
Unit 12 runs 40 service trucks for a regional utility, and its Readiness application tracks each truck's position and status. For one season a 12-person crew from Harlan Line Services works alongside Unit 12. The crew must open Readiness and read Unit 12's shared track feed. It must not write anything, and it must never see Unit 7, Unit 30 or any other tenant.
Identity. Harlan's own OIDC issuer is a second binding on Readiness's crew auth domain, beside the utility's issuer. The host holds both issuers' keys, and a token's claims cannot add an issuer or choose where keys are fetched. A request with no verified sign-in reaches only public entries.
# s/_auth/crew.tri
auth crew {
account = member
methods = oidc | passkey
enrollment = invited
}Application. When a connection opens, the server sets its audience from its own records. Harlan's crew holds partner and nothing more. Every handler that changes data requires crew, so a partner's call to reportDefect stops at the entry with the clause name in the refusal.
# a/audience.tri
flagset audience { crew = 1, partner = 2, dispatcher = 4, admin = 8 }
# s/defects.tri
handle reportDefect(const ctx, u64 truck, text note) require (ctx.audience.has(audience.crew), "crew audience") {
defect.insert({ truck = truck, note = note, reporter = ctx.auth.subject })
}Tenant and data. Every track point carries its tenant. Members of Unit 12 read and write their own points; anyone holding Unit 12's partner relation reads them. A Harlan query for Unit 7 matches the relation on no row, and the reply looks exactly like a query for a unit that does not exist.
# _db/troves/trackPoint.tri
trove trackPoint {
ref tenant tenant
subject<crew> reporter
u64 truck = 0
text status = ""
access (auth<crew> who) {
read = tenant.member(who.subject) || tenant.partner(who.subject)
insert = tenant.member(who.subject) && reporter == who.subject
update = tenant.member(who.subject) && reporter == who.subject
delete = tenant.admin(who.subject)
}
}Service. The server's lend says what the program may touch at all: the trackPoint table for rows, its change feed and its declared queries. It revokes outbound HTTP and child processes. The trove's access block then decides per caller inside that limit.
# _grant/s.draft
u16 schemaVersion = 1
text[] revoke = ["t.net.http", "t.proc"]
chest[] entryStoreSlots = [
{
u16 schemaVersion = 1
text name = "trackPoint"
text table = "readiness/trackPoint"
text access = "readWrite"
text[] database = ["feed", "query"]
}
]Device. The crew's tablets render the feed through the host's display. A program reaches a camera, microphone or other device only through a granted call on a device set its host plan declares. Capture starts only after local consent. The Readiness client on those tablets declares no camera or microphone set, so neither ever opens.
The crew read Unit 12's feed all season. One attempt to file a defect stopped at the entry, naming crew audience, and Unit 7's tracks never appeared in a result, a count or an error. When the season ended, the utility removed the partner relation, and each open partner subscription rechecked before its next delivery and stopped.
System diagram
The request stops at the first refusal and records which boundary made the decision.
Inside the system
Follow the data, decisions, and access boundaries. Each diagram explains a concept used by applications.
Identity, application, tenant, data, service and device each grant on their own. A request needs all of them.
A workload receives only the folders, network paths, programs and devices its grant declares.
Mechanism, tenant, tier, and policy combine into one exact grant.
Each layer grants on its own. A grant to a parent application gives nothing inside a child application or service.
Missing network, tenant, or sandbox posture is an error, not a permissive default.
Key parts
These are the main boundaries, inputs, outputs, and failure rules. The examples show a specific use of each part.
Identity, application, tenant and data, service and device each decide on their own. A pass at one boundary carries no weight at the next, and the refusal names the boundary that made it.
A signed-in partner opens Readiness and still cannot read Unit 7's tracks or file a defect.
A capability is a mechanism, a tenant, a tier and a policy taken together. The mechanism belongs to the platform and stays generic; tenant, tier and policy are the application's data. Tiers belong to each application, so one person can be a plain user in one application and an administrator of their own child application.
Read on trackPoint, for Unit 12, at the partner audience, under the partner relation.
Missing posture is an error, never a permissive default. An admitting host refuses a document of the other form, a governed trove without a protection floor refuses adoption, and an undeclared placement class denies.
A Readiness release that adds an external entry without stating its admission refuses at compile.
Code
Each example is short and complete enough to read on its own. Hover a dotted word for its definition.
The server computes the audience from its own member records, never from anything the client sends. A connection holds exactly the members the server granted, and every require clause and every column audience reads that set.
on event("home", const peerConnection fact) {
if (fact.kind != "opened") { return }
subject<crew>? who = fact.auth.subject
if (who == null) { return }
member? me = member.bySubject.find(who)
if (me == null) { return }
audience granted = audience.partner
if (me.kind == a.people.role.crew) { granted |= audience.crew }
t.net.peer.audience(fact.connection, granted)
send me to fact.connection
}A trove-wide audience row keeps every row from any connection that holds neither member. The server checks it per receiving connection at send time, so the same send reaches a dispatcher and skips a partner.
# _db/troves/unitRoster.tri: never sent to a partner connection
trove unitRoster {
audience = dispatcher | admin
ref tenant tenant
text name = ""
text phone = "" with { pii = true }
}The program reads and writes only the exports anchor, which the host places under the application's data root. Outbound HTTP and child processes are revoked. A lend that pointed an anchor at the application's own directory would refuse, because a program holds no authority over its own source.
# _grant/grant.draft
u16 schemaVersion = 1
text[] revoke = ["t.net.http", "t.proc"]
chest io = {
u16 schemaVersion = 1
chest[] anchors = [
{
u16 schemaVersion = 1
text name = "exports"
text access = "readWrite"
text? leaf = null
text root = "data"
text directory = "exports"
}
]
}Both refusals stop the launch before the program's first call. The first names the revoked library, the function that reached it and the document that revoked it. The second names the anchor that would have reached the application's own files.
tricli: lend: revoked: t.proc
tricli: a.main.main reaches t.proc.spawn, and _grant/grant.draft revokes t.proc
tricli: falseStart: grant
tricli: lend: anchorReachesApplication: cwd
tricli: the anchor's directory is the application directory or holds it, and a program is lent no authority over its own source
tricli: falseStart: grantThis program opens a named key and compares a presented secret. The donor grant lends no security provider, so --reach lists both calls as uncovered. The program cannot launch until the host lends a provider and the lend names the credential.
$ tricli --reach claim.tri
u16 schemaVersion = 1
chest[] uncovered = [
{
text kind = "verb"
text name = "key"
text scope = "t.security.crypto"
},
{
text kind = "verb"
text name = "compare"
text scope = "t.security.secret"
}
]Uses
Review questions
Which tenants, relations and audiences each application needs
Which deployments admit a fixed library list and which revoke from the host default
Which folders, programs and network paths each service really uses
What a refusal may tell each audience, and who reads the detailed reason