OWNERSHIP / APPROVAL / DISAGREEMENT

Matrix agent organization: resolve dual ownership

Inspect product and domain owner votes, distinguish absence from rejection, and count only the decisions already reviewed.

Four independent approval probes

1. Retrieve evidence

WAITING

2. Check the claim

WAITING

3. Write the answer

WAITING

4. Approve release

WAITING

Current snapshot

Synthetic application policies and fixed votes. No live agent, approval identity, ADK Java process or external action is involved.

Separate authority from agreement

This experiment evaluates four independent decisions: retrieve evidence, check a claim, write an answer and approve release. Each has a product owner and a domain owner. An owner can approve, reject or be unavailable. The browser evaluates those votes against the chosen policy; it does not contact agents, execute a task or implement a particular ADK organization API. The four rows are independent policy probes, not a dependent workflow: a blocked research probe does not automatically cancel the other probes. This distinction lets you compare the same ownership rule without pretending that an unperformed task produced an artifact.

Choose what counts as permission to proceed

Require both owners allows work only when both approve. Allow either owner permits work with at least one approval, even when the other owner explicitly rejects it. One approval with rejection veto also needs at least one approval, but any rejection blocks the action. These are three different application policies. Proceeding with only one approving owner is always labeled contested, including when the other owner is merely unavailable. Agreed means both approvals exist. Blocked means the selected policy did not permit work. Contested is never counted as an agreed decision, and none of these simulated outcomes is a recommendation to bypass a real approval requirement.

Scope a failure to the right decisions

Owner incident selects both approve, product unavailable, domain unavailable, product rejects while domain approves, or both unavailable. Incident scope applies that fixture to all four decisions or only to release. The default release-only scope with no incident yields four agreed decisions at the end. Choose product rejects and Require both owners: the first three decisions agree and release is blocked. Allow either owner changes only release to contested. Choose the rejection-veto policy and release is blocked again. Now change the incident to product unavailable: veto policy permits a contested release because nobody rejected it. Both unavailable blocks under every policy; absence never becomes an approval.

Compare exact totals without inventing progress

With incident scope set to all decisions, product rejection and Allow either owner yield zero agreed, four contested and zero blocked decisions. Require both or the rejection-veto rule instead yields four blocked decisions. Every completed probe records exactly two logical owner consultations, so four inspected probes show eight consultations. This is a count of modeled requests, not successful replies, network messages or measured cost. Before playback the summary shows zero inspected decisions and zero totals. At fifteen inspection seconds it includes only the first probe; at thirty it includes two. The remaining cards conceal their owner outcomes until inspected.

Control and record the inspection

Play advances a sixty-second inspection, revealing one decision every fifteen seconds. Pause freezes the clock. Next decision pauses and moves to the next fifteen-second boundary. Restart rewinds while preserving parameters and speed. Time scrubs and pauses; Speed selects quarter, half, normal or double pace and settles elapsed time at the old speed before changing. Parameter changes rewind without autoplay, and hiding the tab pauses. The visible cards and Current snapshot expose identical inspected decisions. Export decisions JSON saves the full computed fixture plus the currently inspected portion. It is explicitly an export, not execution evidence from a production organization.

Keep the boundary of this model visible

Capture baseline saves the visible result and current settings; Replace baseline updates it and Clear baseline removes it. Notebook observations persist locally and Export notes downloads them. Expand experiment and Exit full screen adjust the workspace view. There is no actual approval identity, signature verification, delegation, timeout, mutable policy, escalation or tamper-proof audit store. An unavailable owner has no implicit delegate. Decisions use a single immutable policy and predefined votes; they are not an LLM judgment of whether a proposal is safe. Real matrix ownership requires explicit contracts defining which owner can approve which action and how a disagreement is resolved.

Views are my own and do not represent any employer, past or present.

Search