PAD · pad
Owner directive (2026-07-10), canonical. "The PAD with the Platform Augmenting Data to be used by Procedural Operational Devices (Components, transitions, Interaction)." — confirms C-01: PAD = Platform Augmenting Data. [src: wiki/development/prompts-archive/by-topic/knowledge-management-and-concept-modeling.md:457]
Content
PAD = Platform Augmenting Data (Datasets) — the container card of the kernel of CodeLand (engines). A PAD is the data-holding surface of the UI: glass-blur, z-index stacking, 10 display modes, draggable. PADs hold data; pods hold logic/views. [src: wiki/development/HANDOFF.md:50] [src: wiki/development/REQUIREMENTS.md:43]
In the CodeLand element ladder a PAD is the "container surface — served by an API Gateway" [src: wiki/engines/cognis-and-kernels.md:54], sitting between COMPONENT and pod/SPOT. The cogni of CodeLand is "API Gateways for PADs · WebServices for PODs" [src: wiki/engines/cognis-and-kernels.md:31].
Canonical FUNCTIONAL definition (code). A PADDefinition is a card (glass surface) + a Gateway with the fixed 4-step pipeline verify → validate → augment → disponibilize, plus a model, augmentors and constraints. [src: HOS-Webdoc/web/src/lib/cland/types.ts:6] [src: HOS-Webdoc/web/src/lib/cland/pad-engine.ts:22] The pipeline is executed by executePADPipeline [src: HOS-Webdoc/web/src/lib/cland/pad-engine.ts:53]; every page is wrapped in PADGateway, which runs the four steps on mount (Petra rule K004, petra). [src: wiki/development/REQUIREMENTS.md:46]
Per the D3 ledger ruling, the PAD is a Data Card: "static, inert, encrypted-at-rest repository holding raw data + Cortext preferences + encrypted Vault keys, residing in client-side local storage." [src: HOS-Webdoc/web/src/data/hos-specification.ts:517] The ditto serves as API Gateway for PADs, and pods slide over PADs to create execution (Overlay Mechanic, REQ-CLAND-12 [src: wiki/development/REQUIREMENTS.md:54]). The owner's 2026-07-10 prompt extends PAD use to the spatial-site: "With PAD you may have this platform augmenting the data from graph definitions of the organization, the concepts of the ventures inside it and the knowledge necessary for the joint-endeavor." [src: wiki/development/prompts-archive/by-topic/knowledge-management-and-concept-modeling.md:467]
Variants
| # | Definition (verbatim) | Source | Ruling | Status |
|---|---|---|---|---|
| A | "PAD acronym (C-01) | Platform Augmenting Data/Datasets — the container card. Ignore legacy 'Persistent Anchored Data.'" | [src: wiki/development/HANDOFF.md:133] [src: wiki/development/REQUIREMENTS.md:225] | C-01 → chosen; reconfirmed by OWNER-2026-07-10 ("The PAD with the Platform Augmenting Data…") and D3 ("PAD = Platform Augmenting Datasets") | canonical |
| B | "PAD (Persistent Anchored Data), POD (Procedural Operator Device), OS specification" | [src: knowledge-base/INDEX.md:18] | superseded by A per C-01 ("Ignore legacy 'Persistent Anchored Data'") | deprecated |
| C | "'Platform Augmenting Data/Datasets' (spec) vs 'Persistent Anchored Data' / 'Persistent Action Descriptor' (early docs)" | [src: wiki/development/REQUIREMENTS.md:225] | earliest early-docs expansion; superseded by A per C-01 | deprecated |
| D | Functional: "card: { … surface: 'glass' }, gateway: { endpoint: \/api/pad/${config.id}\, steps: ['verify', 'validate', 'augment', 'disponibilize'] }" — container card with glass surface + 4-step Gateway pipeline | [src: HOS-Webdoc/web/src/lib/cland/pad-engine.ts:22] | canonical functional definition; coexists with A (A names it, D implements it) | canonical |
Open question
Passive vs active contradiction. D3 rules "The PAD is PASSIVE — it cannot run code, only be" [src: HOS-Webdoc/web/src/data/hos-specification.ts:517], yet pad-engine.ts gives the PAD an active verify→validate→augment→disponibilize pipeline [src: HOS-Webdoc/web/src/lib/cland/pad-engine.ts:53].
Proposed reading (unratified): the PAD itself is the passive data card; the pipeline belongs to its Gateway — the API Gateway (ditto-served, per cogni of CodeLand) runs verify→validate→augment→disponibilize on behalf of the PAD. The PAD "is"; its Gateway "does". This matches OWNER-2026-07-10: the PAD is "to be used by Procedural Operational Devices" — execution always sits outside the PAD. Owner to confirm.
Composition
- uses: ditto (its API Gateway / fetch layer), Vault keys (districts Vault), glass card system (petra K003)
- used-by: pod (PODs live inside / slide over PADs), districts (environments hold
pads[][src: HOS-Webdoc/web/src/lib/cland/types.ts:100]), spatial-site, kernel (CodeLand ladder), bp-001-spatial-site
See also
- pod · ditto · dooit · work-units · oss-policy
- [Cognis & Kernels](../../../wiki/engines/cognis-and-kernels.md) · [HANDOFF §1.4](../../../wiki/development/HANDOFF.md)