One identity, per-app lenses
The front door keeps links and grants, not copies of application data.
- Identity one signed-in user
- App lens approved application
- Capability link allowed entry
- Application owns its data
Platform product / System overview
MerTek.io
Release portal and front door for developer services
MerTek.io is the MTK application at mertek.io where teams find releases, read manuals and examples, download builds and keep their developer records. One account signs a person in and routes them to the applications and hosted services their team may reach. Each application still decides what that person may read or change.
Worked example
A transit software team, from download to hosted staging
Northfield Transit's five-person software team builds its bus-maintenance application on MTK, and Sarah Bennett leads it. This week the team needs release 1.4.0 on every laptop and pinned in the repository. It also needs a hosted staging copy for the depot supervisors to try. The supervisors must see only Northfield's work orders.
-
Sarah's team owner invites her, and she signs in with a passkey. The developer account domain admits invited accounts only, so nobody joins Northfield's team by guessing its name.
# s/_auth/developers.tri auth developers { account = member methods = oidc | passkey enrollment = invited } -
She opens release 1.4.0, reads its manual and accepts the license. MerTek.io records the License ID and the legal bundle digest, then issues a download grant for that release. On each laptop the launcher fetches the signed index, checks every object against its digest and moves one pin.
# read and verify the signed release index mertek check # fetch, verify and install the newest edition as one complete generation mertek update # print the active generation, its executables and its release mertek status -
The team pins the repository to that exact release. The pin holds the version, the manifest digest and the digest of every
tricliandtriimage for Windows, Linux and macOS. Anyone who clones the repository runs 1.4.0. A runner from any other release hashes its own image, finds the digest missing fromreleaseRunnersand refuses before the first call.# tri.draft text release = "1.4.0" sha256 releaseDigest = "fcf05d28ca2e9566f51fc417b4d32890d0e61b4477b24926b89bc4d7d6d464bb" sha256[] releaseRunners = [ "be22f8eb1790f1d3666e77048099e1ac8b6d52f237f441de0eca169bc90c9a8f", "5bb91e172b1a58538aade3de749bc3aeac51e9f5ffa73b1a49faff374c59332e", "fdd29ee62803e7ee4edcbface184e2c2057feeedfec2e82057b8512af955f197", "f9e7984f718d0984a22d2b396c424d366f6e05c0c29bcaf4c288e146dac8a50a", "45167a106bc71328ffbf104cfd5114c946326357bc6f45f133d10459eb370785", "eb6e8af280991be4711a5996ca4c74c7e387d24e1ad6802619bb1b2990001c78" ] -
Sarah asks for a hosted staging copy. MerTek.io checks the team's license level and remaining capacity, then sends MerTekStak one authorized, idempotent provisioning request. MerTekStak starts the runtime and returns its durable identity and outcome. A request row on its own never counts as proof that the runtime exists.
-
A depot supervisor follows MerTek.io's link into staging. The staging application runs its own sign-in admission and its own access rules, and it sees the supervisor through its own pairwise subject reference. The link opens the door; the application decides which rows are inside.
trove workOrder { ref tenant tenant subject<workforce> owner text summary = "" access (auth<workforce> who) { read = tenant.member(who.subject) insert = tenant.member(who.subject) && owner == who.subject update = tenant.member(who.subject) && owner == who.subject delete = tenant.admin(who.subject) } }
What happened
By Friday five laptops and the repository ran the same verified build. Supervisors used staging for two weeks and saw only Northfield work orders, because the staging application decided every read. When one supervisor moved to another depot, removing her tenant membership stopped her next request, and her MerTek.io account stayed as it was.
System diagram
Identity does not replace app permission
The user passes several separate checks. A clear sign-in is not a blanket grant.
- Identity maintainer@unit-12
- App grant open Readiness
- Data grant Unit 12 assets • read
- Action view status; edit denied
Inside the system
How the parts work together
Follow the data, decisions, and access boundaries. Each diagram explains a concept used by applications.
Capability tuple
A grant names mechanism, tenant, service tier, and policy together.
- Mechanism what action
- Tenant whose boundary
- Tier which service level
- Policy which conditions
- Grant complete capability
Signup to live application
Identity setup crosses into the control plane only for application provisioning.
- Signup verified identity
- App selection requested lens
- MerTekStak provision approved app
- MerTek.io store capability link
Application generations
A live edit changes stored source and preserves the prior generation for rollback.
- Current source row generation N
- Validated edit candidate bytes
- Publish generation N+1
- Rollback restore generation N
Named refusal cascade
Identity, capability, tenant, tier, policy, and application checks fail separately.
- Identity known?
- Capability present?
- Scope tenant + tier?
- Policy conditions met?
- Application final authority
Key parts
What the system does
These are the main boundaries, inputs, outputs, and failure rules. The examples show a specific use of each part.
Release portal
The publisher uploads Chest metadata and immutable objects, then a signed attestation over the complete inventory. MerTek.io checks the signature, each document's type and every byte, and makes the release visible in one transaction. It holds no release-signing key and never rebuilds or rewrites a release.
For example
An interrupted upload of 1.4.1 never shows: the index serves all of a release or none of it.
One account, many applications
A person signs in once and sees the applications and hosted services their team may reach. MerTek.io keeps links and grants, not copies of application data. Each application receives its own pairwise subject reference and runs its own admission and access rules.
For example
A supervisor reaches staging through MerTek.io, and staging alone decides which work orders she reads.
Developer services
Accounts, teams, license levels, hosted builds and build results live in MerTek.io's own store. Wheelhouse, downloaded or in the browser, reaches the same services, and MerTek.io checks access and capacity before new work starts. Hosted runtimes belong to MerTekStak, with its own store.
For example
An Advanced team queues a Cutlass build from Wheelhouse; the compiler stays on the service, and the team downloads only the built output.
Code
MerTek.io in code
Each example is short and complete enough to read on its own. Hover a dotted word for its definition.
Trident
Serve a release page from a declared endpoint
The endpoint declares its method, path pattern and typed parameters before any handler code runs. A request that does not bind refuses with the declared error document and the real HTTP status. Release rows come from publisher-signed metadata, never from the uploaded artifacts' contents.
private buffer renderRelease(text version) {
return t.buffer.fromText(`Release {version}`)
}
on request({
method = "GET"
pattern = "/releases/{version}"
parameters = [
{ name = "version", source = "path", typeSpelling = "text" }
]
}, const p) {
text version = p.version
return t.net.http.serve.respond(200, [], renderRelease(version))
}Trident
Sign an entitlement without holding the key
A team's license entitlement is a document MerTek.io signs with Ed25519. The key is a credential the host's custodian holds, so the custodian performs every signature and the key never enters the program. Clients check the signature with the published public part.
buffer signEntitlement(buffer entitlement) {
resource<t.security.crypto.key> signer = t.security.crypto.key("entitlement-signing")
return t.security.crypto.ed25519Sign(signer, entitlement)
}
buffer entitlementPublicKey() {
resource<t.security.crypto.key> signer = t.security.crypto.key("entitlement-signing")
return t.security.crypto.ed25519Public(signer)
}Chest
Lend exactly two uses of that key
The lend names one credential and two uses: publish the public part and sign. A defect in the site's code cannot export the key, sign with any other credential or use the key for anything else.
{
u16 schemaVersion = 1
text id = "t.security.crypto"
chest? config = {
u16 schemaVersion = 1
chest[] credentials = [
{ text name = "entitlement-signing", text[] uses = ["ed25519Public", "ed25519Sign"] }
]
}
chest[] storeSlots = []
}Trident
Claim the first administrator
The first admin claim is a deployment secret in the host's credential set, never a compiled-in value. The program hands the presented value to the custodian and learns only whether it matched. Once the admin is recorded in MerTek.io's own store, a second claim refuses by application state.
bool claimAdmin(buffer presented) {
resource<t.security.crypto.key> claim = t.security.crypto.key("first-admin")
return t.security.secret.compare(claim, presented)
}Shell
Roll back a bad update
Rollback restores a complete installed generation: launcher, executables, manifest and artifacts together. It never lowers the trust floor, so an older signed index stays refused after a rollback.
# list the active generation and the retained ones
mertek status
# restore the previous complete generation
mertek rollbackUses
Example uses
- Release discovery and verified downloads
- Team accounts, licenses and developer records
- One sign-in in front of several hosted applications
- Hosted builds requested from Wheelhouse
Review questions
What the team must decide
Which applications each team should reach from MerTek.io
Who on the team accepts license terms and manages members
Whether every repository pins its release in tri.draft
Which hosted services and capacity the license level should include