Machine learning

A project, and a grant that is separate from your role

Two different questions get confused constantly: what work does this belong to, and who is allowed to do it. A project answers the first. A capability grant, held per person per workspace, answers the second.

What a project gathers

Each link is its own junction table, so a project can be assembled and taken apart without rewriting anything.

Datasets

The data the project works on, with the role each one takes.

Features

The feature definitions in scope for this piece of work.

Feature sets

The named groups the project's models consume.

Models

The models the project is about, including the ones it evaluated and rejected.

Integrations

The bindings of a model version to a connection that this project actually calls.

Members

Who is working on it. This is visibility - it says what a person is involved in, and it grants nothing.

How permission actually works

Your role is necessary

The workspace roles that govern everything else still apply. A viewer can read, an editor can write, and nothing about ML changes that.

And the grant is necessary too

The five ML resources additionally require the data scientist capability in that workspace. Both conditions, never either.

The grant narrows and never widens

Holding the capability does not let a viewer write, and outside the ML resources it changes nothing at all.

Revocation is a stamp

Taking the capability away marks the record revoked rather than deleting it, so the history of who could do what, and when, survives.

A regrant is the same record

Granting the capability again to somebody who had it clears the revocation on the existing record rather than accumulating a second one.

Unreadable means denied

If the grant cannot be read, the answer is no. The same rule the trust gate uses, for the same reason.

Why membership grants nothing

The tempting design is to put a role on the project membership: owner, contributor, viewer. It reads well and it creates a second permission system that disagrees with the first one, usually about a person who left a team but stayed on a project.

So membership here records involvement and nothing else. There is one place a permission is decided, and a project cannot quietly become a way around it.

Questions about projects and access

Can an administrator run a model without the capability?

No. The capability is required in addition to the role, and that is true of every role.

Does the capability let somebody see the rest of the workspace?

No. It applies only to the ML resources. Everywhere else, the role decides exactly as it did before.

What happens to a project when somebody's grant is revoked?

The project is unchanged and they remain recorded as a member, because they were one. What stops is their ability to act on ML resources.

Are ML projects tied to a workspace?

Yes. A project belongs to a workspace, which is also where the capability that lets somebody act on it is granted.

Where this is today

The machine learning layer is in build. What is described on this page is the data and governance model that is implemented in the platform: the tables that hold it, the rules that enforce it, and the refusals that happen when a rule is not satisfied.

The Data Science tab is in the application. It reads: the model registry and its versions, the approval held for each version in each environment, the integrations and whether each one may currently be called, the record of every run including the refused ones, the projects, and the egress rules. It does not invoke a model - running belongs to the execution provider, and the record of a run is audit evidence that a browser must not be able to write.

Talk to us about the ML layer

DataLens is in private beta. If model governance is the reason you are here, say so when you request access - the ML layer is being built against real use rather than a roadmap.

Request beta access