GOOGLE DRIVE — MY DRIVE
SOLO / PERSISTENT MEMORY-BANK ARCHITECTURE v0.1.1
Status: CANDIDATE / G1 PASS / FINAL MATERIALIZATION + STATIC READBACK PASS / TEST-READY / UNPROVEN


WHAT THIS IS


A storage architecture for a single primary owner who wants durable state, evidence and working artifacts in Google Drive with fast retrieval, explicit current/history separation and portable identity.


This package does not define the content of your memory/state. The consuming product does that. For example, P081 may define a PROFILE_STATE; this package defines how that state is stored, found, updated, versioned and recovered in Drive.


WHEN TO USE


Use this edition when:
- one person is the primary owner;
- Google Drive My Drive is the selected storage destination;
- persistent state/evidence must survive individual chats or AI sessions;
- fast lookup matters;
- you want a structure that can later migrate to another provider.


Do not use this edition as the default for team-owned continuity. For that, use a Shared Drive or team-storage edition.


PACKAGE


1. START_HERE — this file.
2. STORAGE_ARCHITECTURE_MANIFEST — the governing storage design.
3. OPERATIONAL_REGISTRY — direct lookup and lifecycle index.


CREATE THE ROOT


Create one root folder in My Drive. Give it a purpose-specific name, for example:


MY_AI_MEMORY_BANK
CLIENT_PROJECT_MEMORY
COMMUNICATION_PROFILE_STATE


Inside it create only these top-level folders:


00_REGISTRY_CURRENT
10_STATE
20_EVIDENCE
30_WORKING_ARTIFACTS
90_HISTORY


Do not add deeper taxonomy unless an operational reason requires it.


PLACE THE REGISTRY


Move OPERATIONAL_REGISTRY into 00_REGISTRY_CURRENT.


The registry is the primary lookup surface. A user or AI should locate a current governed object from the registry instead of navigating a long folder path.


STATE


Put current durable state objects in 10_STATE.


Examples:
- PROFILE_STATE
- PROJECT_STATE
- DECISION_STATE
- CONFIGURATION_STATE


The storage architecture does not invent their fields. The consuming product supplies that schema.


EVIDENCE


Put source/evidence objects in 20_EVIDENCE when the state needs auditable support.


Evidence can support multiple states or topics without duplicate copies. Use the registry relations or Drive shortcuts.


WORKING ARTIFACTS


Use 30_WORKING_ARTIFACTS for materials that are active work but are not the authoritative state itself.


Do not let a draft artifact silently become the source of truth.


HISTORY


Use 90_HISTORY only for explicit governed snapshots/retired objects that need independent preservation.


Drive version history is useful recovery support, but CURRENT versus HISTORY is determined by the manifest/registry, not by whichever Drive version happens to be newest.


NAMING


Each governed object receives a stable domain ID from the consuming product or this repository.


Recommended current-object pattern:


<ID>__<HUMAN_NAME>__CURRENT


Example:
PROFILE-001__COMMUNICATION_PROFILE__CURRENT


Historical snapshot:
<ID>__<HUMAN_NAME>__v003__2026-09-18


Do not change the domain ID when moving the object.


DIRECT LOCATORS


For every governed current object, record:
- domain/object ID;
- Google Drive file/folder ID where available;
- direct URL;
- lifecycle state;
- current version.


The exact URL/Drive ID is the locator. It is not the authority.


NO DUPLICATION


Keep one canonical physical copy.


If the same object must appear in another navigation context, use:
- a Drive shortcut; or
- a registry relation.


Do not create duplicate “current” copies.


WRITEBACK


Before changing durable state:
1. Locate the current object through the registry.
2. Read its current version/state_version.
3. Confirm you are changing the current object.
4. Make the bounded update.
5. If the change is materially important, preserve a snapshot/history reference when required by the consuming product.
6. Update the registry after successful write/readback.
7. Never silently overwrite a newer state.


AI ACCESS


If your ChatGPT Google Drive connection exposes the required write actions, ChatGPT may create/update/move supported Drive content after the relevant permissions and confirmations.


If those actions are unavailable, use the same architecture manually. Lack of a live AI action does not change the storage design.


VERIFY


V1 — RETRIEVAL
Choose any current governed object. From OPERATIONAL_REGISTRY, open the direct locator.
PASS: exact object opens in <=1 hop from its owner registry. In routed/scaled mode, the default root path is ROOT_INDEX → one child OWNER_REGISTRY → exact object.


V2 — CURRENT/HISTORY
Check one current object with a historical snapshot.
PASS: only one object is marked CURRENT; history cannot be mistaken for current state.


V3 — MOVE
Move a current object to another permitted folder and update its locator.
PASS: domain ID and logical identity remain unchanged.


V4 — NO DUPLICATES
Search the root for the object's domain ID.
PASS: one canonical current object exists; any additional appearances are shortcuts/history, not competing copies.


V5 — RECOVERY
Restore or inspect a prior version/snapshot according to the manifest.
PASS: previous state can be recovered without changing which state is CURRENT until an explicit rollback decision is made.


V6 — PORTABILITY
Export the registry + current state object.
PASS: the domain identity and lifecycle fields do not depend on the Drive folder path.


LIMITS OF THIS EDITION


- My Drive is individual-owned.
- Google Workspace labels are optional enhancements, not required.
- Automated AI writeback is not claimed unless the exact connected host/account exposes and proves that action.
- Team ownership, SharePoint, Dropbox and multi-store editions require their own adapter proof.




REGISTRATION-FIRST INGEST — CURRENT ADDENDUM — 2026-09-25


P082 has two co-equal operational paths: REGISTRY-FIRST LOOKUP and REGISTRATION-FIRST INGEST.


For every newly created or imported governed object: classify it; assign or preserve a stable object_id; select its canonical destination inside the governed root; write or move it; register it in the authoritative OPERATIONAL_REGISTRY; update any secondary indexes only as derived projections; read back the exact locator and required metadata; and only then mark it ACTIVE/CURRENT when applicable.


If classification is unresolved, keep the object inside the governed root as PENDING_CLASSIFICATION. A physical object that has not completed admission is UNREGISTERED/PENDING_INGEST and must not silently govern execution.


Out-of-band creation or movement must route to provider-appropriate reconciliation. Normal admission is a bounded registration transaction, not a later cleanup task.


FINAL ROUTED INDEX + ADMISSION MATERIALIZATION — 2026-09-28


P082 v0.1 now uses a scalable federated-owner-registry model.


READ:
- Small repository: OWNER_REGISTRY → exact object.
- Scaled repository: ROOT_INDEX → child OWNER_REGISTRY → exact object.
- Default scalable route is one root plus one child registry before the object.
- Deeper registry routing is allowed only when volume/scope materially justifies it and every level is explicitly registered.
- Folder traversal is never the normal discovery method.


AUTHORITY:
- Each governed object has exactly one owner_registry_id.
- Parent/root registries route to child registries through INDEX_ROUTES.
- Parent registries do not duplicate authoritative object rows owned by a child registry.
- Project/domain/type/status views may be derived for navigation, but they are not competing authorities.


OPERATIONAL_REGISTRY now contains:
- OBJECTS — authoritative object rows for the scope owned by this registry.
- INDEX_ROUTES — root/parent routing to child owner registries.
- RECONCILIATION_QUEUE — non-authoritative queue for out-of-band or unresolved objects.
- RELATIONS — cross-object relations.
- WRITE_LOG — governed writes, ingest and reconciliation receipts.
- SETTINGS — edition/runtime rules.


REGISTRATION STATE is separate from lifecycle state:
- REGISTERED
- PENDING_INGEST
- PENDING_CLASSIFICATION
- RECONCILIATION_REQUIRED


A new object is not governed merely because it physically exists in the root. It becomes governed only after classification, stable object_id assignment, canonical placement, registration in its owner registry and locator/metadata readback.


OUT-OF-BAND OBJECTS:
Objects created/moved outside the admission route enter RECONCILIATION_QUEUE or equivalent provider observation. They remain non-governing until reconciliation succeeds.


NORMAL AI START:
Read the root/current registry, route only to the relevant owner registry, then open only the exact objects needed for the task. Do not recursively scan the repository unless reconciliation/discovery is explicitly required


T21 WRITE-CONCURRENCY PATCH — 2026-10-02
Single-primary-writer does not mean stale writes are impossible: manual edits, out-of-band changes, provider restores or another authorized tool can change an object between read and write.


Before every governed update:
1. resolve the authoritative owner registry and exact CURRENT object;
2. read current_version and provider revision/checksum/modified identity when exposed;
3. retain them as expected_current_version and expected_storage_revision;
4. immediately before write, revalidate identity/current_version and provider revision when available;
5. mismatch => WRITE_CONFLICT / RECONCILIATION_REQUIRED; do not overwrite or advance registry version;
6. perform bounded content write;
7. read back content identity/version/revision and required metadata;
8. only after successful object readback update the owner registry and WRITE_LOG;
9. if registry update/readback fails after content write, mark REGISTRY_UPDATE_REQUIRED / RECONCILIATION_REQUIRED rather than claiming a complete transaction.


Provider revision tokens are used when exposed; current_version plus explicit readback remains the portable minimum guard.
.