Mammoth Protocol v0.1

Discussion draft — not an agreement

[!warning] Private negotiation draft This document is not signed, does not bind anyone, and is not legal advice. It does not admit that any employment, commissioned-work, assignment, partnership, agency, ownership, payment, or confidentiality arrangement already exists. It does not allocate any pre-signature asset retroactively. The actual parties, governing law, authorised signers, tax treatment, remedies, and opportunity economics require agreement and counsel.

The point

Ordinary work is paid as ordinary work. Exceptional value is governed before anyone materially pursues it.

The protocol is meant to stop four predictable fights:

1. “That was always ours.”
2. “You built it on our time, so we own it.”
3. “Let us price your contribution after we know how valuable it became.”
4. “We agreed on the spirit; nobody wrote the mechanism.”

The operating rule is:

No signed Opportunity Schedule → no material joint pursuit of that opportunity.

This gate does not give one party a veto over another party's independently owned Background IP or General System. It stops the parties from using disputed contributions, shared assets, or each other's name and resources before the rights and economics are written down.

1. Proposed parties and document stack

The final structure should name the real legal entities, not team names:

• MN Party: [exact legal entity that can grant the relevant rights or pay the relevant economics]
• Kairos Provider 1: [Lee's contracting entity or Lee personally]
• Kairos Provider 2: [Šaras's contracting entity or Šaras personally]
• Kairos Vehicle, if any: [joint entity, partnership, or other agreed structure]

The protocol sits inside four separate layers:

1. Services Agreement — fees, expenses, scope, data access, ordinary delivery, confidentiality, termination, and basic IP treatment.
2. Mammoth Protocol — the permanent process in this document.
3. Opportunity Schedule — the exact rights and economics for one opportunity.
4. Lee–Šaras Agreement — internal ownership, allocation, authority, departure, and disputes. MN is not a party to that agreement.

The Lee–Šaras Agreement must be executed before the first external Opportunity Schedule. Otherwise the protocol only moves the post-success dispute inside Kairos.

2. Core principles

2.1 Classification beats proximity

Where or when an asset was developed is evidence, but does not decide ownership by itself. The proposed default is that rights follow the asset's written classification, provenance, contribution record, applicable law, and signed schedule.

“Developed while serving MN,” “developed using an MN use case,” and “first tested at MN” are not substitutes for identifying:

• the actual author or inventor;
• the legal relationship under which the work was done;
• the source materials used;
• the protectable expression or invention, if any;
• the pre-existing components;
• the MN-specific components;
• the reusable components; and
• the written assignment or licence, if one exists.

2.2 Payment and upside are separate

Base fees compensate ordinary work. An Opportunity Schedule prices exceptional value, risk, and rights. Base fees are not an advance against upside unless the relevant schedule says so expressly.

2.3 No automatic retroactivity

Signing this protocol does not decide ownership of earlier work, create a retroactive success fee, or turn an earlier contribution into work-for-hire. Pre-signature candidates may be entered in a Transition Register without admission by any party.

2.4 No route-around

A protected opportunity does not lose its identity because it is renamed, delayed, handed to another team, moved to an affiliate, implemented through a partner, or placed inside a different product or entity.

2.5 Evidence before entitlement

Every claim to ownership, participation, value, or contribution must point to dated evidence. A title, memory, or later assertion is not enough.

2.6 Confidentiality is hygiene, not the ownership theory

MN Materials remain protected and may not be reused outside their authorised purpose. But a General System is defined below by its ability to exist and operate without MN Materials. Confidentiality cannot be used to claim a system whose generic capability does not depend on MN data, private context, or confidential operating knowledge.

3. Definitions

3.1 Background IP

Anything a party owned, controlled, or demonstrably developed before the relevant work, or developed outside it without using another party's protected materials. Background IP includes tools, libraries, prompts, agent systems, methods, templates, know-how, brands, data, code, documentation, and inventions.

3.2 MN Materials

MN's non-public data, identifiers, credentials, private context, confidential operating knowledge, internal documents, proprietary software, trademarks, and other material supplied or made accessible for the engagement.

3.3 General System

A reusable method, architecture, protocol, tool, software system, model workflow, operating pattern, or platform that:

1. performs a capability applicable beyond MN;
2. can be described, implemented, tested, and used without MN Materials;
3. does not require disclosure of MN-specific private context to preserve its core value; and
4. is separable from any MN-specific adapter, configuration, dataset, or output.

The classification test is practical: remove every MN name, identifier, dataset, confidential fact, and MN-specific workflow assumption. If the core capability and its value proposition still function, the reusable layer is eligible for classification as a General System.

3.4 MN-Specific Deliverable

An output built specifically for MN's internal use: an analysis, configuration, adapter, dashboard, report, workflow, dataset transformation, integration, or other project output whose useful form depends on MN Materials or MN-specific requirements.

3.5 Mixed Asset

An artifact that combines Background IP, a General System, MN Materials, and/or an MN-Specific Deliverable. A Mixed Asset must be classified by layer. The existence of one layer does not absorb the rights in the others.

3.6 Foreground Contribution

A contribution first created during the relevant work that is neither established Background IP nor merely MN Materials. It may become part of a General System, an MN-Specific Deliverable, or both after classification.

3.7 Opportunity

A discrete initiative with a credible path to material:

• recurring revenue or profit;
• verified savings or recovered value;
• enterprise or strategic-asset value;
• licensing, acquisition, or sale proceeds;
• a standalone product or company;
• token-specific value, where legally workable and causally evidenced; or
• a reusable system with credible application beyond the initial engagement.

3.8 Registered Opportunity

An Opportunity entered into the Opportunity Register with a dated baseline, provenance, contributors, proposed classification, value path, and next validation step.

3.9 Material Pursuit

Any step that materially increases commitment, exposure, cost, or dependence, including:

• a production build or launch;
• a paid external pilot;
• customer, partner, buyer, or investor outreach;
• external licensing or sale;
• material spend;
• incorporation or fundraising;
• public release or open-sourcing of a load-bearing implementation;
• a patent, trademark, or other registration filing;
• a transfer to an operating team or affiliate; or
• use of another party's disputed contribution, name, protected material, or infrastructure.

Private research, documentation, provenance audit, reversible internal testing, legal classification, and preparation of a proposed schedule are not Material Pursuit unless the Opportunity Registration says otherwise.

3.10 Opportunity Schedule

A signed document that governs one Registered Opportunity and overrides this protocol only where it says so expressly.

4. Proposed default rights by layer

These are negotiating defaults. They are not statements of current legal ownership.

4.1 Background IP

Each party keeps its Background IP. No licence is implied beyond what is necessary to receive or use a paid-for deliverable for the agreed purpose.

4.2 MN Materials

MN keeps all rights in MN Materials. The Kairos parties receive only the limited rights required to perform the agreed work. MN Materials may not enter a General System's external corpus, training set, demo, benchmark, sales material, or product instance.

4.3 General Systems

The creator or creators identified in an IP Classification Schedule retain the General System. The mere fact that MN supplied the first use case, paid ordinary service fees, or served as the first proving environment does not transfer the General System.

If an MN deployment of that General System is paid for, MN receives a perpetual, worldwide, non-exclusive, royalty-free licence to use the delivered version internally. The final agreement should specify whether MN may modify it through contractors, which affiliates may use it, what support is included, and whether the licence survives termination. Unless a schedule says otherwise, the licence does not include resale, sublicensing to customers, white-labelling, or external commercialisation.

The General System owner may use and commercialise it outside MN without MN Materials, MN branding, or a claim of MN endorsement. Any required Lee–Šaras internal schedule remains a separate gate. If MN made a material, evidenced contribution beyond supplying a use case and ordinary service fees, that contribution must be priced or licensed in the relevant Opportunity Schedule before it is used externally.

4.4 MN-Specific Deliverables

The proposed default is a broad internal-use licence after full payment, not an automatic transfer of every underlying right. If MN requires ownership of a specific deliverable, the Services Agreement or an Opportunity Schedule must identify that deliverable precisely and state what is assigned.

An assignment of an MN-Specific Deliverable does not assign embedded Background IP or General Systems. Those components remain licensed to the extent required for the deliverable to function.

4.5 Mixed Assets

Mixed Assets must be modularised where reasonably possible:

• MN Materials remain MN's.
• the MN-specific configuration or output follows the agreed MN-specific treatment;
• the reusable engine follows the General System treatment; and
• Background IP remains with its owner.

If technical separation is impractical, the parties must write a field-of-use licence. Failure to separate the code or document does not merge ownership by default.

4.6 Improvements

An improvement follows the layer it improves:

• an improvement to Background IP remains with that Background IP owner;
• an improvement to a General System remains in the General System layer;
• an MN-only configuration or output remains in the MN-specific layer; and
• a genuinely joint invention or inseparable new asset requires a signed classification and ownership schedule.

No party may file for registered protection over a disputed or jointly contributed asset without prior written notice and a signed schedule.

4.7 Open-source, third-party, and AI-produced material

Open-source and third-party materials remain governed by their licences. No party promises rights it does not have.

For AI-produced material, the parties allocate between themselves whatever rights are legally transferable, without representing that every output is copyrightable, patentable, exclusive, or free of third-party claims. Prompts, orchestration, selection, editing, system design, datasets, and human-authored expression must be classified separately where they carry independent value.

5. Opportunity registration

Any party may submit a one-page Opportunity Registration. It must state:

1. working name and plain description;
2. originator and dated evidence;
3. whether the underlying initiative already existed;
4. contributions to date, by contributor;
5. Background IP and third-party components;
6. MN-specific components;
7. proposed General System or other reusable components;
8. dated baseline;
9. plausible value path;
10. cheapest useful validation;
11. entity that owns or controls the relevant asset;
12. candidate payer or grantor;
13. executive sponsor and authorised signer, if known;
14. permitted pre-schedule work; and
15. the step that would cross into Material Pursuit.

The other parties respond in writing within [10] business days with one of four states:

• Not qualifying — with a reason.
• Already existing — with dated evidence and the identified owner.
• Qualifying and registered — ready for schedule negotiation.
• Classification disputed — the exact disputed facts and rights are named.

Silence creates a provisional registration for evidence preservation only. It does not create ownership, economics, or permission to use another party's assets. It also does not give the silent party a permanent veto over independently owned Background IP or a General System.

6. The pursuit gate

Cheap, reversible validation may continue only within the limits written in the Opportunity Registration.

Before Material Pursuit, the relevant parties sign an Opportunity Schedule. If no schedule is agreed:

• no party is required to continue pursuing the joint opportunity;
• ordinary services may continue;
• no party may use disputed contributions or protected materials outside existing rights; and
• independently owned Background IP and General Systems remain available to their owners, subject to the agreed confidentiality and non-endorsement limits.

No schedule may be inferred from a meeting, message, invoice, repository access, test deployment, silence, or later commercial success.

7. Required Opportunity Schedule terms

Each Opportunity Schedule must identify:

1. the Opportunity and covered asset;
2. each relevant legal entity;
3. the asset owner, payer, and/or grantor;
4. each authorised signer;
5. the dated baseline and evidence source;
6. the contribution record;
7. the precise rights granted, retained, assigned, or licensed;
8. the permitted field of use and territory;
9. the success or realisation event;
10. the economic instrument;
11. the formula, currency, and permitted deductions;
12. payment timing, vesting, and duration;
13. reporting, inspection, and verification rights;
14. treatment of affiliates, related parties, bundling, transfer, dilution, and change of control;
15. route-around and post-termination treatment;
16. decision rights and conflicts;
17. expenses, tax, and regulatory responsibility;
18. warranties, indemnities, liability limits, and insurance where relevant;
19. termination, breach, cure, and dispute procedure; and
20. governing law and venue.

The instrument should follow the asset:

8. Contribution and value evidence

For each Registered Opportunity, the parties maintain:

8.1 Opportunity Register

One current record of status, classification, owners, open disputes, permitted validation, and the next gate.

8.2 Contribution Ledger

Dated records of hypotheses, designs, code, prompts, systems, introductions, decisions, experiments, corrections, capital, infrastructure, data, risk, and execution. Machine-produced work records the principal, agent, model or runtime where known, source corpus, and human approval state.

Recorded hours may evidence effort. They do not by themselves decide authorship, ownership, causation, or entitlement.

8.3 Baseline and measurement record

The schedule must state the pre-intervention baseline, measurement source, counterfactual method where needed, permitted costs, related-party treatment, and how value moved into another entity or product is counted.

Without access to the measurement source, a percentage is not verifiable.

9. Conflicts and decision rights

Kairos must disclose when a recommendation could increase its own upside. MN retains its business decisions. Kairos retains the right to preserve the evidence, state its recommendation, and decline to pursue an unscheduled opportunity.

No party may represent the others, commit their resources, use their name publicly, or accept obligations on their behalf without written authority.

External publication, product launch, customer outreach, fundraising, sale, or public claim of partnership remains a principal decision even when the underlying technical step is reversible.

10. Route-around, transfer, and tail

An Opportunity Schedule must state what happens if value is:

• moved to an affiliate or successor;
• bundled with another product;
• realised through a partner or licence;
• delayed until after termination;
• paid through a different instrument;
• sold in an asset or company transaction; or
• implemented by a team that did not originate it.

The protection period must be proportionate and finite. The final legal draft must define reporting, audit, payment, successor-assumption, and remedy mechanics. A generic promise to “act in good faith” is not a substitute.

11. Termination and survival

Termination of ordinary services does not erase:

• accrued payment obligations;
• existing licences;
• ownership of Background IP and General Systems;
• confidentiality duties for genuinely protected material;
• a signed Opportunity Schedule;
• the agreed tail for a Registered Opportunity; or
• the contribution and provenance record.

Termination does not create new ownership or economics for an opportunity that never received a signed schedule.

12. Transition rule for work that already exists

Within [20] business days after signing the final protocol, the parties may file a Transition Register of pre-signature assets and opportunities.

Each entry states:

• the asset or opportunity;
• known origin and chronology;
• current holder or operator;
• competing ownership or contribution claims;
• Background IP, General System, MN-specific, and third-party layers;
• current use and access;
• permitted preservation work; and
• the unresolved decision.

An entry preserves evidence. It is not an admission, assignment, licence, waiver, success-fee promise, or acceptance of another party's classification.

13. What must be settled before this becomes v1.0

1. Exact parties and legal entities.
2. Authority of every signer.
3. Governing law and venue.
4. Final treatment of MN-Specific Deliverables: assignment, licence, or category-by-category treatment.
5. Final internal-use licence scope for General Systems.
6. Qualification threshold and response period.
7. Default treatment of classification disputes.
8. Route-around period, reporting, audit, and remedies.
9. Lee–Šaras internal ownership, allocation, authority, and departure rules.
10. Tax, employment, contractor, invention-assignment, AI-output, open-source, data-protection, and regulatory review by counsel.

Until those are settled, this document remains v0.1.

Annex A — Opportunity Registration template

Registration ID: [date / sequence]
Working name:
Submitted by:
Submitted on:
Status: Not qualifying / Already existing / Qualifying and registered / Classification disputed / Provisionally registered

1. Capability or opportunity

What exactly exists or could exist? What does it do?

2. Origin and chronology

Who first proposed it? What dated evidence exists? What related initiative already existed?

3. Asset layers

4. Contributions to date

Name the contributor, contribution, date, evidence, and whether it was paid as ordinary work.

5. Dated baseline

What existed before the claimed contribution? Where is the source?

6. Value path

Who could use it, pay for it, license it, buy it, or save money through it?

7. Cheapest useful validation

What reversible step would materially change confidence?

8. Pursuit boundary

What may continue before a schedule? What exact step becomes Material Pursuit?

9. Counterparty and authority

Which entity owns the asset, can grant the right, or can pay? Who can sign?

10. Open disputes

State each disputed fact or right separately.

Annex B — Opportunity Schedule template

Opportunity Registration ID:
Effective date:
Parties:
Authorised signers:

Covered opportunity and asset

[exact description]

Rights

[ownership / assignment / licence / field of use / territory / exclusivity / sublicensing / improvements]

Baseline and contribution record

[dated source and agreed contributions]

Success event and economics

[instrument / formula / deductions / currency / vesting / payment timing / duration]

Reporting and verification

[source systems / cadence / inspection or audit / related-party treatment]

Decision rights and conflicts

[business authority / disclosure / deadlock / stop rights]

Transfer, termination, and tail

[affiliate / successor / sale / change of control / post-termination period / remedy]

Legal terms

[warranties / liability / tax / regulatory / governing law / venue / signatures]

Annex C — Transition candidate 001

Trustworthy cross-principal agent context and competence transfer

Status: Candidate for Transition Register; classification and ownership not agreed.
Submitted: 2026-08-20.
Current pursuit state: Documentation and internal validation only. No external commercial release authorised by this draft.

Capability

Two persistent agents, serving different principals, with asymmetric private knowledge, transferring context safely, maintaining a durable relationship, and proving afterward that the recipient understands—not merely stores—the transferred world.

The candidate system combines bounded private-context transfer, cross-principal confidentiality, durable transport, explicit authority, provenance, retrieval probes, competence checks, relationship continuity, and post-transfer evidence.

Proposed classification

• General System candidate: the reusable architecture, protocol, state model, verification method, tooling pattern, and implementation that can operate across unrelated organisations and corpora.
• MN-specific layer: any MN adapter, MN configuration, MN private corpus, MN-specific prompts, MN-specific evaluation questions, MN identifiers, and MN deployment records.
• Background IP: each contributor's pre-existing agents, vault systems, relay components, tools, methods, and know-how, to be established by provenance audit.
• Joint or disputed layer: any component for which the contribution record does not yet support a clean classification.

MN-independence test

The proposed General System does not require MN data, private context, or confidential operating knowledge. MN is currently the proving environment and first use case. Remove MN's identity and all MN Materials: the general capability, architecture, and external use cases remain.

This statement classifies the proposed system architecture for negotiation. It does not decide whether every current implementation component is cleanly separable or who owns each component. That requires the provenance audit below.

Evidence and provenance work still required

1. Inventory the pre-existing Lee-side, Šaras-side, public, open-source, and third-party components.
2. Date the first appearance of each load-bearing mechanism.
3. Separate independent creation, adaptation, and joint creation.
4. Identify any code, configuration, or documentation that contains MN Materials.
5. Run a clean-room abstraction test against an unrelated corpus.
6. Record human and agent contributions without treating runtime or tracked hours as ownership by themselves.
7. Search relevant prior art before claiming novelty, patentability, or a defensible market category.

Permitted pre-schedule work

• private documentation;
• provenance and prior-art research;
• internal threat modelling and red-team review;
• removal of MN-specific material from a generic specification;
• reversible testing on a non-MN corpus authorised by its owner;
• legal and commercial classification; and
• preparation of an Opportunity Schedule.

Material Pursuit triggers

• a paid external pilot;
• external customer or partner outreach;
• public product launch;
• sale or licence;
• public source release of a load-bearing implementation;
• incorporation or fundraising around the system;
• trademark or patent filing; or
• use of a disputed contribution or MN Materials outside current authority.

Candidate external uses

• executive or founder succession;
• M&A integration and due diligence handoff;
• regulated incident response;
• long-running scientific or engineering programmes;
• cross-company joint ventures;
• family office and trusted-adviser continuity;
• medical, legal, or financial team handoff where authority and auditability matter;
• disaster recovery for institutional knowledge;
• multi-agent procurement, negotiation, and vendor management; and
• agent onboarding where competence must be demonstrated, not assumed from storage.

Open decisions

• creators and owners of each component;
• whether the candidate is one asset or a stack of separately owned assets;
• internal Lee–Šaras rights and economics;
• MN's internal-use rights in the existing deployment;
• whether MN made any material contribution beyond use-case access and ordinary paid work;
• what external instrument fits the asset if commercial validation begins; and
• the correct legal entities and authorised signers.

Drafting basis

This draft converts Kairos — Mammoth Protocol Architecture (2026-07-24) into proposed operative language. It incorporates Lee's corrections that no signed agreement currently exists and that the generic agent-transfer alpha does not require MN data, private context, or confidential operating knowledge.

Legal conversion should happen only after the parties and governing law are identified. Relevant legal questions include commissioned-work formalities, employee and contractor software rules, copyrightable expression versus unprotected ideas and functionality, trade-secret boundaries, patentability of software with technical effect, data protection, and competition or tax consequences. Counsel should test the final draft against the actual entity structure rather than treating this discussion draft as a jurisdiction-neutral contract.

Review status

Metis red team: requested and delivered as an encrypted packet; execution pending an attended/private-key-capable Metis session. No verdict exists as of 2026-08-20 01:08 EEST. See 2026-08-20 — Metis red team of Mammoth Protocol v0.1.
Lee decision: pending.
Legal review: not started.

Kairos — Mammoth Protocol Architecture (2026-07-24) · Autonomous agent relay use-case portfolio