twins.sgit.ai / actors

Twins as actors

The move that makes the primitive more than a modelling convenience. A twin is not only the thing the graph arrives at, it is the thing that changes the graph, and every change carries the identity and the reasoning of the twin that made it.

1. The claim

"every action that updates the graph, including accepting a risk, is performed by a twin, the acceptor is the twin acting as the CEO or the CFO, connected either to a human or to an agent acting on that human's behalf, with the agent creating the actions, documenting its reasoning and why it chose one option over another, and carrying a persona."

Four things are packed into that sentence, and they are worth separating because they carry different weight.

1

The actor is a twin

Not a username, not a service account. The acceptor is the twin acting as the CEO, which means the actor is itself a modelled object with properties, connectedness and a doorway to a real person.

2

Human or agent, behind the same face

"connected either to a human or to an agent acting on that human's behalf." The graph does not need two mechanisms, because both arrive through the same twin.

3

The reasoning is part of the record

"documenting its reasoning and why it chose one option over another." Not just what was decided. What was rejected, and on what grounds.

4

A persona is carried

The twin acts in a role. The same underlying agent acting as the CFO and as an analyst is two acting contexts, and the record says which.

2. The change pipeline

The mechanism underneath is stated flatly in the source: "the graph is ultimately a set of changes, there is a pipeline for changes, which are fundamentally graph transformations."

That turns governance into something with a familiar shape. A change is a transformation, it has an author, it has a rationale, and it can be reviewed before it lands. The audit trail the risk sites need is not assembled afterwards from logs; it is the same object the change was made with.

The interesting consequence is what it does to risk acceptance. Acceptance is normally the least evidenced act in governance: a signature, a date, and a form. Modelled this way it is a graph transformation performed by a named twin, carrying the options considered and the reason one was chosen, attached to the state of the graph at the moment it happened. It becomes the most evidenced act rather than the least.

3. Where an acting twin gets its hands

An acting twin has a gap in it. It can perform transformations on the graph, because the graph is ours. It cannot perform operations on real systems, because those need credentials, and a twin holding credentials would break the property the rest of the architecture depends on.

That gap is exactly what the execution broker fills, and the two designs compose cleanly:

The acting twinThe execution broker
CarriesThe persona and the reasoningThe credential and the enforcement
AnswersWho is acting, as whom, and whyWhether this exact operation is permitted, now
ProducesA graph transformation, attributableA signed receipt, verifiable
Holds credentialsNoYes, by design

A twin-as-actor performs real-world operations through the broker rather than by holding what the broker holds. This composition is also why the two must not share a name. The naming ruling →

4. State: designed designed

None of this is built. The concrete milestone is the 2FA demo, which would build organisation, HR system, people and roles as twins in IssueFS from the bottom up and put the change pipeline through a real acceptance. It is gap G4, and everything downstream of it labels itself against whether it exists.

5. The question this raises and does not answer

Twins act, and twins are updated. Nothing in the corpus says who may update a twin's definition, which is now the graph's contact with reality and therefore the highest-leverage object in the model. Change the definition of a twin and every measure grounded on it changes meaning.

The broker composition above suggests the answer, in that a change to a twin is itself an operation that could require a mandate and produce a receipt. Nobody has written it. Question 2 →