autonomous intelligent information publishing - MVP

What is being queried — Product (shared drive)

A query never reaches Google Drive. It is answered entirely from an immutable snapshot, which is the only way a mutable, permission-scoped source can honour same query + same epoch ⇒ same answer.

WHO ASKSBrowserplayground, URLsYour appPOST /dslAgentMCP or HTTPONE GRAMMAR, THREE SURFACESGenerated interfaceTier 1: LIST GET COUNT SUM RESOLVE HELPTier 2: 9 entities found in the datavalidation · aliases · fix suggestionsHELP text, generated, in-bandAnswerdata + _meta: epoch, provenance,hints, completeness, relatedrefusals travel as resultsWHAT IS READSnapshot · epoch 1115 canonical rowsimmutable, append-onlyqueries read ONLY thisso the same query alwaysreturns the same answerreadsTHE LIVE SOURCEGoogle Drivegdrive:drv_productmutable, viewer-relativeAdapterprojects to the contractmount and sync onlysync: new epochderef(): the only call that touches the live file — explicitly non-deterministic, and it reports drift

Why not query Drive directly?

Because most of these questions cannot be expressed there. The Drive API has no join, no aggregate, no group-by, and no recursive query, so "which documents are shared outside the company, by owner" is not a request you can make of it — it is a program you have to write. Of 49 operations probed, 23 were expressible against Drive, 20 were not, and 6 were partial.

What the epoch buys

Files move, get renamed, and change permissions while you are reading. An epoch pins the answer, so a number in a report can be re-derived months later and a certificate stays meaningful. Re-syncing opens a new epoch rather than editing this one, so older answers remain reproducible.

Where it is deliberately honest

Google reports no byte size for native Docs, Sheets, or Slides, so a storage total silently covers a fraction of the rows. Rather than hide that, the response carries the coverage and says so in _meta.hints. Same for the trash filter Drive applies invisibly.

The snapshot, as generated for this dataset

Source gdrive:drv_product · epoch 1 · 115 rows · 9 entities · 6 verbs. See the generated DSL

EntityRowsFields Identified by
COMMENTS47ID
DRIVES14NAME
FILES2024NAME
LABELS43FILE_ID
LINKS43SRC_FILE_ID
PERMISSIONS315FILE_ID
PRINCIPALS73ID
REVISIONS86ID
SECTIONS369ID

What is in the snapshot, and what is not

This split is declared by the adapter, not discovered, because it decides which questions can be answered deterministically at all.

resident straight from the source API

  • FILES.ID
  • FILES.DRIVE_ID
  • FILES.PARENT_ID
  • FILES.NAME
  • FILES.MIME_TYPE
  • FILES.SIZE_BYTES
  • FILES.OWNER_EMAIL
  • FILES.CREATED
  • FILES.MODIFIED
  • FILES.MODIFIED_BY
  • FILES.TRASHED
  • FILES.STARRED
  • FILES.WEB_VIEW_LINK
  • DRIVES.*
  • PERMISSIONS.*
  • PRINCIPALS.*
  • REVISIONS.*
  • COMMENTS.*
  • LABELS.*

derived computed at sync time

Not in Drive at all — these are the layer's own claims, which is why they carry a derivation into the envelope. They are also the ones the Drive API cannot express: no join, no aggregate, no group-by.

  • FILES.PATH
  • FILES.DEPTH
  • FILES.IS_FOLDER
  • FILES.ITEM_KIND
  • FILES.SHARED_EXTERNALLY
  • FILES.LINK_VISIBILITY
  • FILES.WORD_COUNT
  • FILES.SECTION_COUNT
  • FILES.CONTENT_HASH
  • FILES.EXTRACT_STATUS
  • SECTIONS.*
  • LINKS.*

remote never resident

Reachable only through deref(), one governed call per item that reports whether the live file still matches the epoch that answered your query.

  • file bytes / native binary content
  • full-fidelity Docs structure (tables, comments anchored to ranges)
  • image and PDF pixel content
  • anything requiring the viewer's own credential rather than the mount's

← Product (shared drive) · playground · DSL reference