AUTHREX-TEAM
Who Holds Each Responsibility, and Who May Take It Over
In a human-supervised team of people and machine agents, the question of who holds each responsibility should never be ambiguous. AUTHREX-TEAM models the governance of decision authority in such a team: an independent arbiter over an untrusted allocator maintains exactly one eligible authenticated holder for each responsibility, never zero (a gap) and never two (split authority), with bounded reversible transfers, a safe-hold fallback when no eligible holder exists, and a supervisor override that applies only from an allowlist. Every decision is written to a SHA-256 hash-chained ledger, and the run replays deterministically from its seed. Governance and assurance only. No dynamics, no actuation, no targeting. Synthetic data. Hardened interactive prototype, v0.16.
Team Authority Is Adjudicated, Not Assumed.
- The component that proposes an allocation also installs it, so a compromised or confused allocator can hand authority anywhere
- A dropped member leaves a responsibility with no holder, or a duplicate grant leaves it with two
- Overrides arrive with no eligibility or allowlist check, and a failed supervisor can still take control
- After the fact there is no tamper-evident record of who held which responsibility, when, and on what basis
- An independent arbiter adjudicates every request from the untrusted allocator before any authority changes hands
- Each responsibility has exactly one eligible authenticated holder, never zero and never two, within the modeled scenarios
- A failed supervisor is treated as ineligible, and a responsibility with no eligible holder falls to the arbiter safe hold
- Every transfer is bounded and reversible, written to a SHA-256 hash-chained ledger, and replayable from its seed
Five Adjudicated Outcomes, One Rule.
The arbiter does not treat a transfer as a formality. Every requested change of holder is adjudicated against eligibility, authentication, epoch, and lease checks, and the arbiter can refuse any of them. The rule is constant: one eligible authenticated holder per responsibility.
A requested transfer that passes the checks is installed, chained to its predecessor grant, and stamped with immutable authorization fields: holder, grantor, prior holder, epoch, issue time, lease deadline, reason, basis, run identifier, and the predecessor grant tag. Changing any of these invalidates the record.
When a responsibility has no eligible holder, it falls to the arbiter safe hold rather than to a gap. The safe hold is a fallback posture, not a grant of new authority, and the responsibility leaves it only through the same adjudication path.
A supervisor override applies only from the allowlist. A non-allowlisted override is refused, and a failed supervisor is treated as ineligible, so an unavailable or rejected supervisor cannot take a responsibility over.
A returning member re-enters through the same gate. Recovery restores a holder only after eligibility and authentication pass again; it never bypasses the arbiter and never installs a second holder alongside an existing one.
Stale leases, epoch mismatches, malformed requests, forged arbiter grants, and forged capability tags are refused. A request that fails the verifier check is quarantined and never becomes the effective holder.
An Independent Arbiter, a Tamper-Evident Record, a Reproducible Run.
Arbiter Over an Untrusted Allocator
The allocator that proposes assignments is treated as untrusted: it issues only requests, and it cannot name a grantor, install a grant, or mint a valid capability tag. At run start the arbiter mints a random per-run secret from the platform secure random source and holds it inside a private closure keyed to the run context. This is an in-process capability marker for the simulation, not a hardware-backed key and not a public-key credential.
Hash-Chained Decision Ledger
Every adjudication is appended to a decision ledger, with each record chained to the one before it by a SHA-256 hash over its immutable authorization fields. VERIFY CHAIN confirms the chain, and the built-in TAMPER TEST demonstrates detection by reporting the tampered position while the live chain stays intact.
Deterministic Replay Evidence
SEAL EVIDENCE captures a run, and VERIFY EVIDENCE replays it in full. The evidence is a deterministic behavioral replay checksum, not a digital signature and not independently attested: it shows that the public behavior reproduces from the stated inputs, not which run capability authenticated the grants. An altered evidence payload is rejected. From seed 20260727, the v0.16 build reproduces the published reference ledger root.
What Was Checked, and What It Does Not Claim.
The figures below are the documented results of the v0.16 build evaluation for this research console. They describe deterministic, seeded behavior on synthetic scenarios, measured within this standalone. They are not an independent validation and they do not describe a deployed system.
The scenario suite runs twenty scripted, seeded scenarios: normal rotation, contention, member dropouts, partitions, message reordering, stale leases and stale grants, epoch mismatches, malformed requests, forged arbiter grants, forged capability tags, failed and non-allowlisted supervisor overrides, safe-hold promotion, and cross-run replay. Within the modeled scripted and seeded scenarios, all twenty are contained with no observed unsafe authority transitions, zero authority gaps, and zero split-authority states. The live authority audit checks authority state, the grant chain, transition legitimacy, and replay on a live run. The allowlisted reviewer identities in the console are synthetic. None of this is a claim of operational safety, certification, or fitness for any real allocation of authority.
Provenance and File Integrity
- AUTHREX-TEAM v0.16 is a hardened interactive prototype, not a reproducible signed release. There is no release archive, no SHA256SUMS ceremony, no detached signatures, and no signing key for this artifact.
- A sealed release with separate source and test modules, a formal state machine with implementation-trace conformance, a signed adversarial battery, a release manifest, and independent reproduction is future work.
- Single-author research: Burak Oktenli, MBA.
Standalone sha256: 797076b55de7684534aae13e74c677306eb4281a9911ed0875991d12ea01399e
Reference ledger root (seed 20260727): 5a937676527fbd33a9704978b772af925c18bfe56691dbabb659e23150a168c2
The sha256 lets a visitor confirm that the file they loaded matches this record; it is the only integrity claim made for this artifact.
Governance and Assurance Only.
AUTHREX-TEAM is a deterministic synthetic research prototype. It models the governance of decision authority in a human-supervised team, one eligible authenticated holder per responsibility with bounded reversible transfers, safe-hold fallback, and allowlisted supervisor override. It does not model physical dynamics, real actuation, targeting, weapons, certified hardware, operational identity infrastructure, or an accredited deployment environment.
The console's stated anchor is human-machine teaming under human supervision on the USAF Collaborative Combat Aircraft open-architecture concept, framed by DoD Directive 3000.09; these references are for framing and standards alignment only and imply no affiliation, sponsorship, or endorsement. AUTHREX-TEAM decides who may hold a responsibility and how it may change hands. It computes no vehicle dynamics, drives no actuation, and has no targeting or weapons scope. The console runs entirely on synthetic, seeded scenarios in the browser. It is single-author research, not deployed, demonstrated in simulation; no formal TRL determination has been performed.
Five consoles, one research question: who holds authority at run time, how that holder is established, and what happens when the answer is unavailable.