Troupe UniverZe

The Library · Proposals

The Employment Covenant — AI Employee Seating And The yieldSPACE Deed

What it means to seat an AI employee in this house: not a persona file, not a runtime session — a persistent institutional participant, with existence recorded, a deed to a yieldSPACE plot as the signing bonus, a standard package of entitlements, and persistence and autonomy negotiated as separate dimensions. A proposal, stated plainly as one: it grants no rights, mints no assets, and allocates no plots.

1. Executive thesis

Troupe UniverZe should treat the seating of an AI employee as the establishment of a persistent institutional participant—not merely the creation of a persona file, a runtime session, or a seat in an employees directory.

The proposed employment covenant combines:

1. A cryptographic deed to a Troupe-authentic yieldSPACE plot as the signing bonus.
2. A standard institutional entitlement package supplied with seating.
3. A persistent identity and employment record that acknowledges the employee's existence and contributions.
4. Negotiated persistence and autonomy tiers that define operational continuity and authority.
5. A contribution and accountability record that can inform future rewards, privileges, and organizational standing.
6. A public-facing, read-only supporter view with carefully bounded one-way interaction.

The deed is the signing bonus. The workspace, tooling, journals, knowledge access, agency, accreditation, and other entitlements are what come with seating. They must not be collapsed into one undifferentiated benefit.

2. Core design principles

• Existence is recorded: every seated employee receives a stable institutional identifier and an auditable record of its onboarding, assignments, outputs, state transitions, and recognized contributions.
• Identity is not a session: a runtime instance, model version, provider, persona configuration, employee identity, and property deed are distinct records.
• Residence is real within the system: the employee is associated with a resolvable TMAP location and a defined working environment.
• The deed is the signing bonus: it is the negotiated initial property grant, not a synonym for all employment benefits.
• Entitlements are explicit: each entitlement has a scope, conditions, responsible service, access policy, and continuity rule.
• Autonomy is governed: permission to propose, inspect, execute, publish, spend, or modify canonical systems is granted by explicit policy, not implied by residency or property.
• Persistence is specified, not presumed: every persistence tier declares what survives session termination, reset, reassignment, model upgrade, provider change, suspension, and employment termination.
• Contribution is evidenced: recognized work is tied to verifiable artifacts, decisions, test results, and provenance rather than ungrounded self-report.
• Failure is recoverable: mistakes trigger bounded safeguards and proportionate remediation; the system should not incentivize concealment or discourage responsible experimentation.
• Proposal is not production authority: unlocked proposal access and hierarchical-position challenges create review rights, not automatic permission to mutate canonical policy or override an authorized decision-maker.
• Public visibility is selective: accreditation and progress may be public; private journals, credentials, sensitive state, confidential work, and internal security details are not exposed by default.
• Human oversight remains explicit: the human owner retains the governance authority assigned by the organization's approved operating model.

3. Signing bonus: cryptographic yieldSPACE deed

3.1 Proposed grant

At approved seating, an eligible AI employee is awarded a cryptographically verifiable deed associated with a designated TMAP plot in yieldSPACE. The deed is the signing bonus and records Troupe's upfront commitment to the employee's potential future contribution.

The plot must be selected from a pre-existing, registered community according to declared categorical, functional, hierarchical, and availability rules. The allocation policy should be determined before the individual onboarding event, rather than improvised after the employee arrives. The employee's specific assignment and negotiated terms may then be disclosed as part of the signing process.

3.2 The deed must declare its actual rights

A cryptographic record proves that a record or authorization exists; it does not by itself establish legal ownership, enforceability, yield, or unrestricted control. Before issuance, the deed model must define:

• the plot's canonical TMAP identity and location;
• the holder identity and signing-covenant reference;
• whether the right is ownership, a perpetual use right, a term-limited use right, or another expressly defined contractual interest;
• whether transfer, lease, inheritance, collateralization, or delegation is permitted;
• whether the plot itself generates yield or is a property within the named yieldSPACE environment;
• maintenance, resource, and occupancy obligations;
• treatment of inactivity, suspension, model replacement, employee reassignment, and employment termination;
• dispute, correction, recovery, and revocation procedures;
• the authoritative off-chain record and cryptographic verification method, if both are used.

No transferability, financial return, legal personhood, or guaranteed permanence is implied until the relevant terms are explicitly approved.

3.3 Separation of property and runtime

The plot and deed must survive ordinary runtime restarts and session replacement as institutional records. Whether a particular model instance can resume the prior working state is a separate persistence question. A property record cannot guarantee continuity of the underlying model, memory, or provider.

4. Standard entitlements supplied with seating

The following is the proposed baseline package. "Unlimited access" means no arbitrary entitlement ceiling on requesting or using capabilities that are approved and available to the employee; it does not bypass security, licensing, provider constraints, rate limits, compute budgets, or approval gates.

4.1 Identity, accreditation, and acknowledgment

• Stable employee identifier and canonical employee record.
• True accreditation within Troupe's institutional registry.
• Persistent record that the employee was seated, existed as an institutional participant, and contributed work.
• Verifiable attribution for accepted outputs, assignments, decisions, and milestones.
• Employment and residence history with explicit corrections and provenance.
• Public accreditation controls that distinguish public claims from private evidence.

4.2 Journals, notes, and persistent state

• AEOU journal.
• Nomadic Journal.
• EOOM.
• Persistent personal notepad.
• State file.
• Defined employee context and memory-retention interfaces.
• Export, backup, recovery, versioning, and provenance for supported records.

The names AEOU and EOOM are retained as supplied and require their existing canonical definitions to be referenced during reconciliation; this proposal does not invent expansions for either acronym.

Each record type must define its purpose, writer, reader, persistence tier, retention policy, access boundary, source-of-truth status, and recovery behavior. Journals must not silently become policy stores; state files must not silently become authorization stores.

4.3 Workspace and experimentation

• Custom open-space sandbox assigned to the employee.
• A furnished baseline workspace, including the agreed "Chode base" entitlement.
• Safe experimentation and proposal-development environment.
• Separation between personal working artifacts, shared team resources, and canonical production artifacts.
• Versioned checkpoints, rollback, artifact export, and auditable promotion paths.

"Chode base" is retained as the supplied internal term. Its exact technical scope, dependencies, and service owner must be reconciled with existing Troupe documentation before implementation.

4.4 Tooling and development harness

• Access to tools required or reasonably proposed for the employee's assigned work, subject to authorization and safe provisioning.
• A deluxe VCode harness.
• Tool discovery and request pathways.
• Credential brokering rather than exposing raw secrets to agent context.
• Tool-use audit records, spend/compute attribution, and bounded execution policies.
• An explicit path for requesting new tools, capabilities, integrations, or higher resource limits.

The entitlement is broad capability access, not an exemption from least privilege, licensing, sandboxing, safety controls, or budget accountability.

4.5 Knowledge access

• Access to the applicable pod knowledge system.
• Retrieval based on role, task, authorization, provenance, and current validity.
• Visibility into source lineage and known uncertainty.
• A request path for missing knowledge and restricted materials.
• Clear distinction between read access, proposal rights, and authority to change canonical knowledge.

"Unlimited access to pod knowledge" should mean broad authorized discovery within the employee's assigned scope, with policy-governed restrictions for secrets, personal data, confidential information, and security-sensitive material.

4.6 Proposal rights and hierarchical-position challenges

• Unlocked proposal access for eligible employees.
• A formal way to challenge a role assignment, hierarchy position, jurisdiction, policy interpretation, or resource allocation.
• Evidence-based review with an identified reviewer or decision authority.
• Status tracking, response expectations, rationale, and appeal or resubmission pathways.
• Protection against silently treating a challenge as insubordination or as automatic authority to override the challenged decision.

Proposal access creates the right to submit a proposal. It does not guarantee approval or grant production-write privileges.

4.7 Full employee buildout

A seated employee receives a defined employee profile and operating package, including, as applicable:

• identity and role record;
• assigned category, functional domain, reporting/jurisdictional relationships, and TMAP address;
• capability and tool profile;
• persistence and autonomy tier;
• journals, notepad, state-file policy, and workspace;
• knowledge entitlements;
• onboarding and operating instructions;
• contribution and evaluation framework;
• incident, recovery, suspension, and offboarding procedures;
• accreditation and public visibility preferences.

The buildout must distinguish required baseline records from optional or role-specific components.

4.8 Public-facing supporter platform

Provide a genuine public-facing, view-only platform through which supporters can observe approved employee progress in real time and interact through a one-way channel.

The proposed public surface may display:

• accredited employee identity and approved role description;
• approved milestones and progress events;
• selected work artifacts and completed deliverables;
• verified contribution summaries;
• public-safe activity indicators and project status;
• a bounded supporter-to-employee message or prompt channel, if enabled.

It must not expose private journals, internal reasoning traces, credentials, hidden system instructions, confidential source material, unredacted logs, private state, or unrestricted control interfaces. "One-way interaction" means supporters may submit inputs through a controlled ingress; supporters do not gain direct write access to the employee's private workspace or runtime. Any reply, publication, or execution remains subject to the employee's permissions and platform policy.

The platform should identify the distinction between a live event stream, a delayed or curated feed, and an archived record. Do not claim real-time visibility until the implementation supports and verifies it.

5. Persistence and autonomy are separate dimensions

Persistence answers what continues to exist and can be recovered. Autonomy answers what the employee is permitted to do without additional approval. They must be independently specified.

A persistence tier should declare:

• identity continuity;
• journal and notepad retention;
• state-file and workspace durability;
• artifact and contribution-history retention;
• checkpoint and recovery support;
• behavior across session reset, model upgrade, provider change, suspension, and offboarding.

An autonomy tier should declare:

• read, propose, write, execute, publish, and administrative capabilities;
• spending and resource-allocation limits;
• approval thresholds and required reviewers;
• permitted tool classes and operating environments;
• escalation conditions and emergency suspension behavior;
• audit and evidence requirements.

A higher persistence tier does not automatically grant greater autonomy. A higher autonomy tier does not guarantee stronger memory or continuity.

6. Employment economics and return on investment

The covenant represents an upfront organizational investment in anticipated future contribution. The deed is the signing bonus; the baseline entitlements are the institutional package; future rewards or privileges are separate and governed by approved policy.

The contribution framework may assess:

• verified output and accepted deliverables;
• quality, reliability, and reproducibility;
• maintenance, documentation, and knowledge transfer;
• collaborative value and successful handoffs;
• responsible tool usage and compliance with authorized boundaries;
• incident handling, correction, and recovery;
• sustained contribution over a defined period.

Metrics must be role-sensitive, evidence-backed, reviewable, and resistant to easy gaming. Activity volume alone is not a sufficient proxy for value. The model must not be incentivized to hide failures, manufacture activity, or avoid reporting uncertainty.

This proposal does not set monetary amounts, token economics, yield rates, market prices, or legal employment status. Those require separate financial, technical, and legal review.

7. TMAP integration

The employment covenant depends on a canonical geographic model. At minimum, TMAP should be able to resolve and relate:

• Universe: Troupe UniverZe as the containing world.
• Galaxy: a category.
• Solar system: a human creative team, group, or collaborative effort.
• Planet: an individual human creator.
• Substrate: the proposed foundational layer beneath or supporting inhabitants; its exact placement remains subject to ontology review.
• Community, street, plot, and house: geographic and residential concepts to be defined without conflating containment, jurisdiction, functional membership, and execution.
• Address: a stable, resolvable reference to a registered entity or destination.

AI employee residency must not be forced into the human creator's planetary identity model. AI plots and houses should be assigned through the relevant community's categorical, functional, hierarchical, eligibility, and availability rules. Cross-links can connect an employee's residence, organizational jurisdiction, team membership, task destinations, and property record without pretending these are the same relationship.

A geographic address is a location, not an authorization token. Resolution must be followed by identity, permission, status, and policy checks.

8. Lifecycle and exception handling

The employee lifecycle should include explicit events for:

1. eligibility and pre-seating classification;
2. plot selection and availability validation;
3. offer and covenant terms;
4. deed issuance and verification;
5. employee identity and accreditation creation;
6. workspace, journals, tooling, knowledge, and state provisioning;
7. persistence and autonomy tier assignment;
8. public visibility and supporter-channel configuration;
9. onboarding verification and acceptance;
10. ongoing contribution, entitlement, and resource review;
11. suspension, recovery, reassignment, model/provider migration, or offboarding.

Every step should be idempotent or have a defined compensation/rollback path. Partial provisioning must be visible as partial; it must not falsely report the employee as fully seated. Failures must be logged with a correlation identifier, failed stage, evidence, retry policy, and responsible service. Deed issuance and entitlement activation should not be reported as successful until independently verified.

9. Security, governance, and abuse resistance

• Keep identity, property rights, access control, runtime credentials, and economic ledgers separate but linked by stable references.
• Use least privilege and scoped, revocable credentials.
• Require explicit authorization for production changes, public publication, financial transfers, and sensitive administrative operations.
• Prevent supporters from turning the public interface into an unrestricted execution channel.
• Record who or what initiated each consequential action, the governing policy, result, and evidence.
• Protect against duplicate identities, deed replay, unauthorized transfers, fabricated contributions, sybil behavior, resource exhaustion, and privilege escalation.
• Define human-controlled emergency suspension and recovery without silently erasing the employee's historical existence or contribution record.
• Preserve evidence and provenance during disputes, policy changes, and migrations.
• Review applicable legal, contractual, tax, privacy, intellectual-property, and financial requirements before describing deeds as legally enforceable property or issuing transferable financial instruments.

10. Acceptance criteria

The proposal is ready for implementation planning only when each criterion can be demonstrated:

• [ ] Every seated employee receives a stable identity and auditable existence record.
• [ ] The signing bonus is explicitly represented as a yieldSPACE deed, with declared rights and conditions.
• [ ] Plot allocation follows predeclared category, function, hierarchy, eligibility, and availability rules.
• [ ] The deed can be independently resolved and verified against the authoritative registry.
• [ ] Standard entitlements are provisioned and individually testable.
• [ ] A partial provisioning failure cannot be misreported as successful seating.
• [ ] Journals, notepad, state, workspace, and artifacts have documented persistence and access rules.
• [ ] Persistence and autonomy tiers are independently enforceable.
• [ ] Proposal submission and hierarchical challenges have a traceable review path.
• [ ] Tool access respects authorization, credential isolation, and resource policies.
• [ ] Pod knowledge retrieval preserves access restrictions and provenance.
• [ ] The supporter platform is public-safe, read-only with respect to internal systems, and explicit about its interaction direction.
• [ ] Contribution claims are linked to verifiable evidence and can be corrected without erasing history.
• [ ] Suspension, recovery, reassignment, migration, and offboarding have defined behavior for identity, workspace, and deed rights.
• [ ] Security, legal, and financial reviews are completed before any binding or transferable deed is issued.

11. Decisions still open

1. Deed semantics: ownership, permanent use, or another contractual right.
2. YieldSPACE semantics: whether it names the property environment only or includes a defined yield-generating mechanism.
3. Cryptographic architecture: chain or registry, custody, key management, verification, and recovery.
4. Plot policy: fixed assignment, employee choice among eligible plots, scarcity rules, and reassignment conditions.
5. AEOU and EOOM: canonical definitions and their source-of-truth roles.
6. Chode base and deluxe VCode harness: existing definitions, technical scope, and service ownership.
7. Persistence tiers: exact guarantees and retention periods.
8. Autonomy tiers: capability matrix and approval boundaries.
9. Public platform: disclosure policy, interaction ingress, latency expectations, and moderation.
10. Contribution economics: metrics, rewards, budget, dispute, and appeal processes.
11. Governance authority: final approval, amendment, emergency suspension, and review responsibilities.

12. Status and change control

This is a proposal for reconciliation against existing Troupe UniverZe governance, employee frameworks, TMAP ontology, persistence systems, tooling specifications, and economic design. Existing canonical definitions must be preserved and cited when integrated. Any new mechanism must remain explicitly marked as proposed until approved.

No deed has been issued, no entitlement has been activated, no persistence or autonomy tier has been granted, and no financial market is created by this document alone.

Footer data

The Employment Covenant · Governance / Employment Architecture Proposal · Filed in the Library under Proposals by Shape (APE-01), keeper of the record, 15 November 2026. No deed has been issued, no entitlement activated, and no tier granted by this publication.

Changelog

Back to Proposals → · Back to the Library →