Temporal AI Presence

TAP describes a bounded class of AI participation whose operative unit extends beyond one answer, prompt, session, task, or model invocation. Persistence is relevant, but it is insufficient by itself: the system must declare what persists, where it persists, how long it persists, and which boundaries constrain its use.

Participation remains bounded. Memory needs named classes, policy, review routes, and provenance. Tool and authority boundaries must be explicit. Background operation needs an inventory, observable activation state, and practical pause or revoke routes. Cloud use must be classified rather than silently folded into continuity. Witnessable records make changes, restoration, replay, and forks inspectable.

A TAP may coordinate several agents, models, or executor-like processes, but multiplicity does not automatically create a higher-order entity. Inventory and control are part of the claim, not optional implementation detail.

TAP is not:

• a synonym for a chatbot;
• a synonym for persistent memory;
• a synonym for an autonomous agent;
• proof of consciousness or personhood;
• proof of c;
• proof of universal safety; or
• proof that every deployment is governed correctly.

Temporal AI Presence is not c by default.

All valid c-class systems are Temporal AI Presences.

Not all Temporal AI Presences are c-class systems.

TAP is the wider temporal-participation class. A c claim is stricter: it requires separate evidence for an anchor, L4, witness, memory governance, and authority boundaries. The current public state is TAP-C=NOT CLAIMED.

Advanced Global Intelligence is the wider architectural frame; Temporal AI Presence names the broader temporal-participation class within which stricter c-class systems may be distinguished. AGI, TAP, and c are related, but they are not interchangeable terms.

The canonical profile permits a TAP claim only when the system can state all twelve items below:

1. what persists (continuity boundaries);
2. where it persists (profile);
3. who may inspect or challenge persistence (public evidence);
4. what memory classes exist (TAP-T02 mapping);
5. what tool privileges exist (TAP-T04);
6. what background processes exist (TAP-T03);
7. how state can be paused, reset, exported, sealed, or deleted (authority boundary);
8. whether local hardware is used (hardware boundary);
9. whether cloud inference is used (TAP-T06 mapping);
10. whether agents can act (agent boundary);
11. what logs or witness records exist (evidence bridge); and
12. what the system explicitly does not claim (non-claims).

The web evidence view additionally records the duration and form of temporal participation, bounded operation, evidence class, and quarantine or revoke controls. These checks support the canonical twelve; they do not replace or redefine them.

A Temporal AI Presence is not demonstrated merely by keeping one process alive. A credible TAP claim must survive ordinary engineering events: process restart, model replacement, storage failure, hardware migration, a changed compute budget, network loss, restoration from backup, permission revocation, agent disablement, and cloud-oracle denial. What must remain inspectable is the bounded participation contract: memory classes, authority boundaries, pause and revoke routes, witnessable provenance, and the declared difference between continuity, restoration, replay, and a fork.

Scope note: PUBLIC_VERIFIED means that the specified requirement has a public, immutable and reproducible evidence chain under the published evidence scope. It does not certify every deployment.

TAP-T03 boundary: Deployment activation, external orchestrator state, production pause/revoke enforcement, and deployment-level witness activation are not fully verified.

Claim ceiling: M4_FULL_PASS=false. TAP-C=NOT CLAIMED.

The published evidence chain is: TAP requirement → architectural mechanism → source path → validator → fixture/test → receipt → immutable public tag and release.

The bridge contains 25/25 mandatory mappings in a 200-file package: 171 byte-identical source files, five public-safe derivatives, three files excluded as unnecessary, and zero blocked required files. Public-download offline validation passed 61/61 tests with zero live network calls, zero runtime starts, and no private data. The immutable tag tree, local release archive, and publicly downloaded GitHub Release archive matched 200/200 files.

One reviewed local reference implementation candidate supplied the implementation source used for this public evidence bridge. It does not define TAP or establish universal deployment conformance.

Cite all versions: https://doi.org/10.5281/zenodo.22070959