Ownership#

A finding is only useful if somebody answers for the resource. Hyvop keeps one record of who that is for each resource, finds candidates from evidence, and lets a person confirm. A plan is approved by the people confirmed here and by nobody else.

The screens#

Menu group Ownership.

A resource has its own page (/ownership/resource) with its roles, the evidence collected for it and its timeline. Confirming, assigning and removing people are for administrators.

The contract: roles and what they mean#

For each resource, Hyvop keeps a list of people, each with a role, the kind of that role, a confidence, a state, who decided, and the evidence. Several people can hold the same role. The role keeps the words somebody wrote ("Service Owner", "Code Owner and Team Lead"); the kind is what the rest of the product reasons about, whatever the words.

A word like "Team Lead" on its own is the kind Approves, not Accountable. If you want somebody to answer for a resource, confirm them in a role that is accountable.

States of a person on a resource#

Re-certification due. A confirmation does not last for ever. After 180 days (a setting, core.env.OWNERSHIP_RECERTIFY_AFTER_DAYS) Hyvop records one request, and the resource is listed under Re-certification due on Ownership > Unassigned. Nothing is cleared meanwhile: the roles stay. Confirming the same person again is the answer, and it renews the date.

Validated means somebody is accountable#

A resource is validated when somebody is confirmed as accountable for it, and only then. Confirm a maintainer or an approver and the person is confirmed, but the resource is not validated. If the last accountable person is removed, the resource goes back to suggested.

No resource is validated without a person: auto-validation is off as shipped. An administrator can allow Hyvop to accept a suggestion backed by two independent sources (core.env.OWNERSHIP_AUTO_VALIDATION=two-sources); the confirmation then shows the score and the sources.

A finding on a resource with no accountable person is Blocked until somebody is confirmed (findings.md).

How an owner is found#

Hyvop looks for evidence in this order of trust. Only the last step uses a model.

1. Facts the cloud holds. Read by code, with no model:

• who created the resource, who last changed it, the stack that made it, the account it is in. These come from the cloud's own records and tags (such as aws:createdBy, aws:cloudformation:stack-name), from tags people write for the purpose, and from the tags on the bill;
• a deployment manifest: a pipeline can tell Hyvop who owns, operates and manages what it deployed (the API for it takes an API key). That is a declaration, it does not fade, and a resource it names a person for is not sent to a model.

Only an address names a person. An IAM user, a role, an application or the root account names nobody.

A limit to know on AWS: the bill carries the creator only if the cost allocation tag aws:createdBy is switched on in the account (Billing, Cost allocation tags). On an account as AWS ships it, the bill names no creator. On Azure and GCP the cloud's own creator record is not read yet; creator tags that people write still count.

2. The people who work on it. If a GitHub organisation is connected (Data Sources > Discovery Sources, /integrations?tab=discovery), Hyvop builds a graph from GitHub, read-only: repositories, CODEOWNERS files, who committed and when, who opened and reviewed pull requests, teams and their members. Someone the graph calls an outside contributor is given no role unless a CODEOWNERS file declares them. GitHub is the source that is built; GitLab and Jira as sources are not.

3. The Investigator (a model). It reads the resource's identifier and tags and what the graph holds for them, and proposes findings: this person, in this role, because of this evidence. Everything it says is checked before it counts.

An agent may suggest who is accountable, but only on strong evidence: a declaration, or a recent link showing that the person creates, commits to or deploys what the resource is made from. A reviewer or a member of a team is not enough, and neither is old evidence. Such a finding is labelled as a suggestion until a person confirms it, and nothing is validated automatically by default.

A declared team does not end the investigation. When a tag or a manifest names only a team, the team is recorded as a finding and the model is still asked for a person, with the team and its neighbours in the graph as context. This costs model calls: one investigation per workload that names only a team, once for all of its resources. To save the calls and stop at the team, set core.env.INVESTIGATOR_MODEL_FOR_DECLARED_TEAMS=false.

Checking what the model said#

Every finding the model proposes goes to a judge, which is code, not a model. It refuses a finding when:

• the person is not in the context the model was shown (and no address in a tag names them);
• it cites something that was not in that context, or an edge that does not exist;
• the person is no longer active;
• the role does not follow from the links: a reviewer is not a committer, and an accountable role needs a declaration or strong evidence.

A refused finding is sent back with the reason, up to three times. After that it is escalated: it is saved with no person and a reason, nobody is suggested from it, and it is listed on Ownership > Unassigned under "Findings the judge sent back". The same list shows "Resources a stage gave up on" and "Re-certification due". Together they are the escalation list: everything that needs a person, with Hyvop's reason and a link to the resource.

Who a finding names: keys, never names#

Hyvop decides who a finding is about by keys, each from the source that owns it: the person's id, the login on its Git host, a whole address from a directory or a tag. Two people holding the same key means the key names neither. Names never merge: look-alike names are put on the finding as "possibly the same person" for you to decide.

Evidence, and how old it is#

Each piece of evidence is weighted by its kind. A tag that names the owner, a CODEOWNERS entry and a manifest count more than a name that merely looks right. The weight fades with the evidence's own age (the date of the commit or of the creation), not the age of the record. Then:

• each further independent source adds a little;
• a source that names somebody else, or a person who has left, lowers the score;
• the model's own confidence can only lower the score, never raise it.

The score is shown as a percentage on the suggestion. On the resource page, "Evidence collected by the agents" lists each piece in a sentence: who, from which source, and when. A principal that names nobody is marked "Names no person".

What is sent to a model, and what is not#

Hyvop calls a model only when an administrator has set one up (ai.md). Until then nothing is sent anywhere.

Two rules hold everywhere.

No rows of your data. A prompt carries the names and types of tables and columns, never a row of them. Two things carry values, and both are metadata Hyvop produced: a finding (resource identifier, saving, state) when the assistant is asked about findings, and the identifier and tags of a resource being investigated.

No names of people, unless you say so. Wherever a person would be named, the prompt carries a stand-in (person-3, address-2), and Hyvop puts the people back before it stores or shows the answer. The model learns that somebody commits to a repository; it does not learn who. An administrator can choose to send names as they are, for the whole install (core.env.AI_PERSONAL_DATA=as-is).

Team, repository, channel and resource names are not treated as personal data and are sent. A person named inside free text nobody declared, such as the title of a merge request, is not recognised and goes with that text; an e-mail address in it is still replaced. The log at its normal level holds no question, answer or prompt.