4 - Self_Documenting_Base_Architecture.docx

SYSTEM ARCHITECTURE DOCUMENTATION Self-Documenting Base Architecture Field Inventory, Canonical Routing, and Cascading Permissions Base > Stack > Table > (Field x Record) One semantic model for documentation, routing, permissions, and migration Architecture scope OBSERVED SCHEMA Field Inventory CANONICAL MODEL B > S > T > F x R ADDRESSING 12.2.2.2.5 AUTHORIZATION Levels 0-7 Version 1.0 | August 2, 2026 Conceptual specification with Airtable reference implementation Contents Section Topic 1 Introduction and Core Terms 2 Field Inventory 3 Base, Stack, Table, and Field x Record Model 4 Canonical Routing System 5 Cascading Permission System 6 Individual and Organization Base Ownership 7 End-to-End Operating Examples 8 Implementation Model and System Invariants 9 Glossary Appendix A Airtable Field Inventory Script Appendix B Permission Resolution Pseudocode Reading guide The document separates stable semantic identity from live platform state. Canonical markers identify what an object means in the system. Airtable IDs identify the current material object. Inventory records describe what is currently observed. Routes connect those layers, and permissions determine which subjects may traverse or operate on each route. 1. Introduction and Core Terms This architecture turns a base into a system that can describe, locate, inspect, and govern its own components. It is designed so that the same conceptual model can operate inside Airtable today and survive migration to another runtime later. The architecture is built from four cooperating layers: Field Inventory: a live observation table that records the fields currently present in the base. Canonical hierarchy: Base > Stack > Table > (Field x Record), which defines how every object fits into the system. Routing: a fixed semantic address that identifies any base, stack, table, field, record, or exact field-record intersection. Permissions: a cascading Default + Override model evaluated along the same route used to identify the object. 1.1 Why the terminology matters The system depends on using different words for different kinds of identity. A table name can change. A table may move in a diagram. An Airtable table ID remains stable while that table exists. A canonical table marker remains stable even if the implementation moves to another platform. Treating those as separate concepts prevents documentation, diagrams, and permissions from breaking when presentation changes. Term Working definition Base The top-level operational container. A base receives a system-wide base marker and contains one or more stacks. Stack A logical layer above tables that groups related tables and system components into a functional domain. Table A structured collection of records and fields. It is identified by both a canonical marker and a platform ID. Field A named, typed property defined for records in a table. Record One instance or row in a table. A canonical record marker can be assigned independently of the platform record ID. Field x Record The intersection of one field and one record: the exact cell or value coordinate in the system. Canonical marker A stable semantic number such as S02, T10, F14, or R00217. It is a reference, not a live position. Platform ID The current runtime identifier, such as an Airtable tbl..., fld..., or rec... ID. Observed metadata Facts detected from the live base, such as current names, field types, IDs, active status, and timestamps. Declared metadata The intended meaning, purpose, ownership, symbols, canonical markers, expected behavior, and governance rules. 1.2 Architecture at a glance Canonical Map <-> Observed Inventory <-> Routing <-> Permissions Each layer describes a different part of the same system Layer Primary responsibility Canonical map Defines stable markers, intended grouping, names, symbols, and the original design of the base. Observed inventory Scans the live base and reports current IDs, names, types, status, first-seen time, and last-seen time. Base Network Diagram Renders the current network while retaining canonical markers as labels and references. Routing resolver Maps a semantic route to the current platform objects that instantiate that route. Permission engine Evaluates the subject, route, inherited defaults, overrides, ownership mode, and requested action. 1.3 Core design principles Stable identity is separate from visual order. Marker 10 remains Table 10 even if it appears first, last, or in another stack view. Names are readable labels, not permanent identity. IDs and canonical routes preserve continuity through renames. Declared and observed metadata remain separate. Automated scans should not overwrite human descriptions, intent, or policy. A route identifies the target once. Documentation, diagrams, permissions, logs, checks, and migration tools reuse that route. Blank and zero are different. Blank means inherit; zero means an explicit denial. Every permission decision should be explainable from the route and the rules that won. Deleted objects are normally retired, not forgotten. Their markers and history remain available for audits and diagrams. 2. Field Inventory The Field Inventory is the observed metadata layer for fields. It creates one inventory record for each field discovered in the base and keeps that record synchronized with the live Airtable schema. The inventory is factual: it records what currently exists. Canonical markers and descriptions can be stored alongside it as declared metadata without being overwritten by the scanner. 2.1 Required table schema Field name Airtable type Purpose Inventory Key Single line text Primary field and unique identity for the table-field pair. Table Name Single line text Current table name observed during the latest scan. Table ID Single line text Permanent Airtable table ID while the table exists. Field Name Single line text Current field name observed during the latest scan. Field ID Single line text Permanent Airtable field ID while the field exists. Field Type Single line text Airtable internal field type returned by the scripting API. Active Checkbox Checked when the field currently exists; cleared when it is no longer observed. First Seen Date with time When the inventory first discovered the field. Last Seen Date with time The most recent successful scan in which the field was observed. Exact-name requirement The automation script references these field names exactly. Spelling and capitalization must match. The primary field must be Inventory Key. 2.2 Inventory key and live identity Each field record uses a composite key made from the current Airtable table ID and field ID: tblABC123456:fldXYZ789012 Inventory Key = Table ID + colon + Field ID The composite key prevents duplicates, survives table and field renames, and allows the script to recognize an existing field record on later runs. The readable names are refreshed; the IDs preserve platform continuity. 2.3 Canonical marker extension The required inventory fields above are enough for live schema tracking. The canonical architecture adds stable semantic markers. These values should be assigned once from the canonical map or a first-discovery allocation routine, then preserved even when the live object moves or is renamed. Optional field Example Purpose Stack Marker S02 Identifies the parent stack in the canonical base map. Table Marker T10 Stable marker for the table within its stack. Field Marker F14 Stable marker for the field within its table. Canonical Field Route 02.10.14 Compact semantic route to the field inside the base. Canonical Status Mapped / Unmapped / Conflict Shows whether the observed field is correctly attached to the canonical map. Declared Description Human-authored text Explains purpose, source, expected use, and business meaning. Marker rule Canonical numbers are markers, not current array positions. If Table T10 moves, it remains T10. If Field F14 moves, it remains F14. The Field Inventory reports its current observed name, type, ID, and active state; the Base Network Diagram changes its placement while preserving the marker. 2.4 Marker allocation policy 1. At canonical setup, assign stack, table, and field markers from the initial approved base map. 2. When a new object is added later, assign the next valid unused marker within its parent scope or use an approved reserved marker. 3. Never renumber an existing object merely because its display order changes. 4. When an object is deleted, retain its marker in history and normally retire it from reuse. 5. If the same platform ID returns through restoration or undo, reactivate the existing mapping. If a new platform ID is created, treat it as a new object unless an authorized remapping is recorded. 2.5 Automation setup Create the inventory table in the base being documented, then configure a scheduled Airtable automation. 1. Create a table named exactly Field Inventory. 2. Delete unnecessary default fields and create the required fields listed in Section 2.1. 3. Set Inventory Key as the primary field. 4. Open Automations and create a new automation. 5. Choose At a scheduled time as the trigger. 6. Choose a refresh interval. Daily is suitable for stable bases; hourly is suitable for rapidly changing schemas. 7. Add a Run a script action and paste the reference implementation from Appendix A. 8. Test the trigger, test the script action, and inspect the resulting Field Inventory records. 9. Name the automation, turn it on, and confirm the schedule. 2.6 Synchronization workflow Stage Operation 1. Read Load existing Field Inventory records and index them by Inventory Key. 2. Observe Scan every table and field currently exposed to the script. 3. Compare Match observed fields to existing inventory records using Table ID + Field ID. 4. Create Create a new inventory record for each previously unseen field. 5. Refresh Update names, type, Active, and Last Seen for fields that still exist. 6. Retire Mark previously active inventory records inactive when their field is no longer observed. 7. Report Return fields found, records created, records updated, and records marked inactive. 2.7 Expected automation outputs A first run may report: fieldsFound: 67 recordsCreated: 67 recordsUpdated: 0 recordsMarkedInactive: 0 A normal later run may report: fieldsFound: 67 recordsCreated: 0 recordsUpdated: 67 recordsMarkedInactive: 0 Refreshing all active records is intentional. It updates Last Seen and captures changes to table names, field names, and field types. 2.8 Recommended views View Filter Use Active Fields Active is checked Sort by Table Name, then Field Name. Deleted Fields Active is unchecked Preserves a simple history of fields no longer present. Recently Added No filter required Sort First Seen from newest to oldest. Unmapped Fields Canonical Status is Unmapped Shows live fields not yet attached to the canonical map. Mapping Conflicts Canonical Status is Conflict Shows duplicate or invalid marker assignments. 2.9 Schema-change behavior Change Inventory result New field added A new inventory record is created. Field renamed The existing inventory record receives the current Field Name. Table renamed All matching field records receive the current Table Name. Field type changed Field Type is updated. Field deleted The existing inventory record is marked inactive. Table deleted All field records belonging to that table are marked inactive. Field recreated with the same name A new record is created because the new field has a different Field ID. Deleted field restored with the same ID The existing record becomes active again. Field moved visually Canonical marker remains unchanged; live status and diagrams may update placement. 2.10 Relationship to the Base Network Diagram The inventory and the canonical diagram serve different purposes. The canonical map records stable meaning and original organization. The inventory records current observed implementation. A diagram generator joins them by canonical marker and platform ID, then renders the current state with stable labels. Canonical marker + Platform ID + Observed state -> Current diagram node Stable reference, live identity, and current presentation remain separate 3. Base, Stack, Table, and Field x Record Model The model introduces a level above tables called a Stack. A Stack groups tables and system components that belong to the same functional domain. At the table level, fields and records form two independent axes. Their intersection identifies an exact cell or value. 3.1 Hierarchy Base > Stack > Table > (Field x Record) Broadest container to exact data coordinate Level Meaning Base Top-level environment for one operational system or bounded application. Stack Functional grouping of tables, such as Operations, Finance, Documentation, or System Control. Table Collection of records governed by a shared field schema. Field Vertical schema axis: what property is being addressed. Record Horizontal instance axis: which entity or event is being addressed. Field x Record Exact value coordinate created by intersecting one field with one record. 3.2 Why Field x Record is an intersection A field does not identify a complete value by itself, and a record does not identify one property by itself. The precise address of a cell requires both axes. This supports granular documentation, validation, logging, and permission checks without inventing a separate object model for cells. F14 x R00217 = the value at Field 14 in Record 00217 The cell coordinate is derived from two stable axes 3.3 Stacks as a semantic layer Stacks are part of the canonical model even if the current platform does not expose them as a native structural object. A Stack can be represented by a Stack Inventory record and used to organize tables, interfaces, automations, scripts, documentation, and permissions. A stack marker is stable even when the visual presentation changes. A table belongs to one canonical stack at a time unless the system explicitly supports aliases or cross-stack views. Cross-stack relationships are represented as routes, not by duplicating the underlying table. Permissions can be granted at the stack route and inherited by all descendant tables and records. 3.4 System components use the same model Interfaces, automations, scripts, views, forms, permission layouts, checks, and logs can be represented as records in dedicated system tables. Once represented as records, they receive routes, permissions, owners, dependencies, health signals, and audit history using the same system as operational data. Component Representation Documented properties Automation Record in an Automation Inventory table Purpose, trigger, expected interval, status, last run, errors, dependencies. Interface Record in an Interface Inventory table Audience, source tables, visible fields, intended workflow, owner. Script Record in a Script Inventory table Version, inputs, outputs, dependencies, run history, source location. Check Record in a Check Definitions table Rule, schedule, target route, severity, expected result. Finding Record in a Findings table Exact target route, discrepancy, first seen, last seen, status, resolution. 3.5 Identity layers Identity layer Example Purpose Canonical identity S02.T10.F14 Stable semantic meaning inside the system. Platform identity tbl... / fld... / rec... Current runtime object used to read or write the live platform. Readable identity Invoices / Payment Status Current human-facing names, which may change. Observed state Active, type, last seen Current implementation status reported by inventory scans. Historical identity Retired marker and prior names Preserves lineage after deletion, migration, or replacement. 4. Canonical Routing System The routing system extends canonical markers across the full ecosystem. A route is a stable semantic address that can locate a base, stack, table, field, record, or exact cell. The same route can be used by documentation, diagrams, checks, permission rules, logs, links, exports, and future offline runtimes. 4.1 Full route format B165132617146.S02.T10.F14.R00217 Expanded symbolic route 165132617146.02.10.14.00217 Compact fixed-width route The compact route is self-parsing because the segment order and width are fixed. Spaces may be added to the twelve-digit base marker for human readability: 165 132 617 146.02.10.14.00217 Human-grouped base marker with the same routing meaning 4.2 Segment anatomy and capacity Segment Symbol Width Range Namespace capacity Base B 12 digits 000000000000-999999999999 1,000,000,000,000 values Stack S 2 digits 00-99 100 markers per base Table T 2 digits 00-99 100 markers per stack Field F 2 digits 00-99 100 markers per table Record R 5 digits 00000-99999 100,000 markers per table Capacity planning These widths define the canonical namespace, not the platform limits. If a parent scope could exceed its range, widen the segment or define an extension before the namespace fills. Never silently reuse an active or retired marker. Reserving all-zero values for null, system, or unspecified routes reduces assignable capacity by one per scope. 4.3 Markers are references, not sequence positions A route segment does not promise that objects appear in numeric order. T10 may be shown before T03 in a network diagram. F14 may be the first visible field in a specialized interface. The marker tells the system which canonical object is being referenced, not where it must appear today. If the live order never changes, marker order and display order align naturally. If the live order changes, markers remain stable while the inventory and diagram report the new arrangement. A route remains usable across migrations because it is not an Airtable object ID. 4.4 Partial routes Route Target 165132617146 The entire base. 165132617146.02 Stack 02 in the base. 165132617146.02.10 Table 10 in Stack 02. 165132617146.02.10.14 Field 14 in Table 10. 165132617146.02.10.R00217 Record 00217 in Table 10 using expanded notation. 165132617146.02.10.14.00217 The exact Field 14 x Record 00217 value coordinate. 4.5 Route resolution A route resolver translates semantic markers into the current platform objects. It should never depend on names alone. 1. Parse and validate each fixed-width segment. 2. Resolve the Base marker to the current base registry entry. 3. Resolve the Stack marker within that base. 4. Resolve the Table marker within that stack and retrieve its current platform Table ID. 5. Resolve the Field marker and Record marker within that table when present. 6. Confirm that each mapping is active and not in conflict. 7. Return the platform IDs, current names, status, and requested object or value coordinate. 8. Log unresolved, retired, ambiguous, or permission-denied routes as structured findings. 4.6 Routing rules Rule Requirement Uniqueness A marker must be unique within its immediate parent scope. Immutability An assigned marker does not change because of a rename, reorder, or diagram move. No silent reuse Deleted markers remain retired unless an authorized historical-reuse policy explicitly allows reuse. Explicit remapping A canonical route may be remapped to a new platform object only through a recorded transition. Fixed parsing Compact routes must preserve declared segment widths and order. Status aware Resolution reports active, inactive, retired, missing, and conflict states. Portable The canonical route must not embed a platform-specific identifier. 4.7 Routing system components A system component is routable when it is represented as a record. For example, an automation may be stored as Record 00042 in an Automation Inventory table. That record can then be addressed, permissioned, linked to fields, checked for health, and included in diagrams. B165132617146.S01.T08.R00042 Example route to an automation inventory record Fields on that record can be addressed more precisely. If Field F06 is Last Successful Run, the exact value is: 165132617146.01.08.06.00042 Exact route to an automation health value 4.8 Portability and migration Canonical routes survive platform migration because platform IDs are stored as mappings rather than embedded in the route. Airtable can be the first execution environment while the semantic address remains the long-term identity. A later offline runtime only needs to replace the platform mapping layer. Canonical route -> Runtime mapping -> Current database object Change the runtime mapping without changing the semantic address 5. Cascading Permission System Permissions use the same route hierarchy as the object model. A subject receives an effective permission by combining inherited defaults, explicit overrides, ownership mode, conditions, and protected-action rules. The result is both machine-enforceable and human-explainable. 5.1 Permission scopes Name Scope Controls B-Perms Base permissions Visibility and access to the base as a whole; root participation and base-level governance. S-Perms Stack permissions Access to a functional stack and its descendant tables and components. T-Perms Table permissions Access to table structure, fields, records, and permitted table operations. R-Perms Record permissions Access to specific records and, when combined with field scope, exact values. Field restrictions are evaluated inside the table permission domain. The field segment can receive a table-scope rule without requiring a separate top-level permission family. For an exact cell, the engine evaluates both the field axis and the record axis. 5.2 Two tiers: Default and Override Default inheritance + Explicit override = Effective permission The two tiers use the same permission levels Default permissions define the normal access cascade. An object with no local default inherits the nearest parent default. Overrides are explicit exceptions assigned to a subject, role, team, layout, script, automation, API client, or other principal. Critical distinction Blank means inherit. Level 0 means explicitly deny. A database implementation must store those as different values; otherwise a missing rule can accidentally become a denial or a denial can accidentally disappear. 5.3 Permission levels Level Name Core capability 0 No Access Cannot discover, view, or operate on the target. 1 View Structure Only Can see names, schema, relationships, routes, and permitted documentation, but not record details. 2 View Details Can view permitted record data and component details. 3 Add Records Can create new records but cannot directly edit existing approved records. 4 Suggest Edits Can submit proposed changes for review without applying them directly. 5 Full Editor Can create and directly edit ordinary operational data and permitted configurations. 6 Owner or Key Holder Individual Base: non-revocable Base Owner. Organization Base: protected Key Holder. 7 Organization Owner / Full Access Final organizational authority; used only for Organization Bases. 5.4 Capability ladder Levels 0-5 form the normal operational ladder. Higher levels include the ordinary capabilities below them unless a protected action has a separate approval rule. Levels 6 and 7 are governance states and must not be treated as ordinary inherited editor levels. Capability L0 L1 L2 L3 L4 L5 View schema and routes Yes Yes Yes Yes Yes View record details Yes Yes Yes Yes Create records Yes Yes Yes Propose edits Yes Yes Directly edit ordinary data Yes 5.5 Default inheritance A default permission continues downward until a descendant declares a different default. This makes broad access easy to establish and specific boundaries easy to add. Base default: 1 Stack 02 default: blank -> inherits 1 Table 10 default: 2 -> replaces inherited default Record 00217: blank -> inherits 2 The effective default for Record 00217 is Level 2. 5.6 Override behavior An override replaces the default permission structure for the matching subject and route. It normally cascades to descendants until a more specific override replaces it. Base default: 1 Stack 02 default: 2 Table 10 default: 3 Jordan override at Stack 02: 4 Jordan override at Record 217: 0 Jordan receives Level 4 throughout Stack 02, including Table 10, except for Record 217, where the more specific Level 0 override wins. 5.7 Saved permission layouts A permission layout is a reusable collection of route assignments. Layouts can be assigned to people, teams, roles, departments, scripts, automations, API clients, and service accounts. Layout: Stack Contributor Base: 1 Stack 02: 3 Table 10: 4 Table 11: 2 Restricted set: 0 A direct subject override can adjust one route without duplicating the entire layout. Permission layouts therefore operate as reusable templates, while overrides handle exceptions. 5.8 Precedence order Priority Source Resolution role 1 Ownership state Valid Level 6 or Level 7 authority is resolved separately and cannot be removed by lower rules. 2 Direct subject override Most specific explicit rule assigned directly to the subject. 3 Higher-priority overlay layout Security, legal, or temporary layouts that intentionally supersede ordinary role layouts. 4 Primary layout or role rule Reusable permission profile assigned to the subject. 5 Nearest inherited default Most specific default found along the target route. 6 Fallback If no rule exists, resolve to Level 0. Within the same source class, the most specific target route wins. A record override outranks a table override, which outranks a stack override, which outranks a base override. 5.9 Field and record intersection For an exact cell, the engine resolves the field axis and record axis separately. The default result should be the more restrictive effective permission unless an explicit cell override is authorized. Table effective level: 5 Field F14 level: 0 Record R00217 level: 5 Cell F14 x R00217: 0 The subject may edit other fields on the record but cannot discover or access Field F14. This makes the Field x Record model directly useful for granular permissions. 5.10 Suggest Edits workflow Level 4 does not directly mutate approved data. It creates a proposal record that can be reviewed and applied by an authorized editor. Proposal field Purpose Target Route The exact field, record, or component being changed. Current Value Value observed when the suggestion was created. Proposed Value Requested replacement or new value. Submitted By / At Subject and timestamp. Reason Why the change is requested. Review Status Pending, approved, rejected, withdrawn, or superseded. Reviewed By / At Reviewer and decision timestamp. Applied At Timestamp when an approved change reached the target. 5.11 Dynamic conditions A permission rule may depend on current system state. Conditions refine access after route and rule resolution. Level 5 when Record Owner equals Current User. Level 2 when the subject belongs to the Finance department. Level 0 when Classification equals Restricted. Level 4 while Approval Status equals Pending. Level 2 after a contract end date. Level 3 only while a submission window is open. Conditions must be logged with the decision so that access remains explainable. 5.12 Protected actions Level 5 Full Editor covers ordinary operational editing. It does not automatically grant irreversible or ownership-level authority. Protected actions are checked separately after the effective level is resolved. Protected action Required authority Delete a base Level 6 in an Individual Base; Level 7 or organization policy in an Organization Base. Transfer ownership Current final owner through a recorded transfer process. Permanently purge protected records Owner or authorized key-holder process, especially for legal or retention-sensitive records. Override a legal hold Explicit protected authority and recorded reason. Modify root permission policy Final owner or specifically delegated governance authority. Appoint or revoke key holders Level 7 Organization Owner. Delete audit history Normally prohibited or subject to a dedicated retention policy. 5.13 Permission decision logging Every permission decision should be capable of producing a structured explanation. This makes the system auditable and lets the Base Quest Center show exactly why access was allowed or denied. Log field Purpose Decision ID Unique event identifier. Timestamp When the decision was made. Subject User, team, role, automation, script, or API client. Target Route Canonical route being accessed. Requested Action View, create, suggest, edit, delete, transfer, execute, or another operation. Resolved Default Nearest inherited default. Applied Layout Permission layout that contributed to the result. Applied Override Winning explicit override, if any. Ownership State Individual owner, key holder, organization owner, or none. Condition Results Dynamic tests and outcomes. Effective Level Final resolved level. Decision and Reason Allow or deny with a human-readable explanation. 6. Individual and Organization Base Ownership The meaning of the highest permission levels depends on whether the base is individually owned or organization owned. This keeps the individual model simple while allowing companies to separate operational key custody from final organizational control. 6.1 Individual Base Levels 0-6 | Level 6 = Base Owner Level 7 is not used An Individual Base has exactly one recognized Level 6 owner. Level 6 is a non-revocable ownership state, not merely a higher editor permission. Ordinary defaults, layouts, and overrides cannot reduce the owner below Level 6. The owner has permanent access while ownership remains assigned to them. The owner holds final permission authority and protected-action authority. The owner may transfer ownership through an explicit transfer process. A transfer must be recorded and accepted before the previous owner loses Level 6. The base must never be left without a valid owner. Immunity from lockout A Level 6 Individual Base Owner cannot be removed through a permission override, layout change, or descendant rule. The only valid removal is a completed ownership transfer. 6.2 Organization Base Levels 0-7 | Level 6 = Key Holder | Level 7 = Organization Owner Operational custody is separated from final authority In an Organization Base, Level 6 becomes a protected Key Holder rather than the final owner. Level 7 is the Organization Owner or equivalent full-access authority. Authority Role Level 6 Key Holder Approves or unlocks protected operations, may co-sign destructive actions, supports recovery and continuity, and can be rotated or revoked by Level 7. Level 7 Organization Owner Holds final organizational authority, appoints or revokes key holders, controls ownership transfer and root governance, and cannot be removed by lower levels. 6.3 Individual versus organization comparison Capability Individual Base Organization Base Highest level 6 7 Level 6 meaning Base Owner Key Holder Level 7 meaning Not used Organization Owner / Full Access Can Level 6 be revoked? No; only replaced through ownership transfer Yes; by Level 7 under governance policy Final ownership transfer Performed by current Level 6 owner Performed by valid Level 7 authority Protected-action approvals Owner directly, with optional confirmations Level 7, optionally with Level 6 key-holder approval or quorum Continuity anchor Individual owner Organization owner 6.4 Ownership transfer 1. Current final owner initiates transfer to an eligible recipient. 2. The system records the source owner, proposed recipient, base route, timestamp, and reason. 3. The recipient accepts the transfer using the required authentication and approval process. 4. The system atomically activates the new owner before reducing or changing the prior owner status. 5. The ownership version increments and an immutable transfer log is created. 6. If acceptance fails or expires, the current owner remains unchanged. 6.5 Organization protected-action models An organization may choose the approval pattern that fits the risk of the action. Level 7 remains final authority, while Level 6 key holders provide custody, co-signature, or operational separation. Model Operation Single-owner approval Level 7 alone authorizes the action. Owner plus key holder Level 7 initiates and one Level 6 key holder approves. Key-holder quorum Level 7 initiates and a defined number of Level 6 key holders approve. Dual key Two distinct Level 6 key holders approve; Level 7 governs policy and can suspend the process. Delayed execution Approval starts a delay and recovery window before irreversible execution. 7. End-to-End Operating Examples 7.1 Field rename without identity loss Field F14 in Table T10 is renamed from Payment State to Payment Status. The Airtable Field ID remains the same. The next Field Inventory run updates Field Name and Last Seen. The canonical route remains unchanged: 165132617146.02.10.14 Same semantic field, current readable name updated The Base Network Diagram can display the new name while links, permissions, checks, and historical findings continue to use F14. 7.2 Field moves but marker remains stable Field F14 is moved to the first visible column in an operational view. F14 does not become F01. The marker remains the reference to the canonical field. The live diagram may change placement, and the inventory continues to report the same Field ID, name, type, and status. 7.3 Stack contributor with a record exception Base default: 1 Stack 02 default: 2 Contributor layout at Stack 02: 4 Direct override at R00217: 0 The subject may suggest edits throughout Stack 02 but cannot discover or access Record 00217. The permission decision log identifies the record override as the winning rule. 7.4 Sensitive field on an otherwise editable record Table T10 effective: 5 Record R00217: 5 Field F14: 0 Cell F14 x R00217: 0 The user can edit the record except for the protected field. The cell permission is restricted by the field axis. 7.5 Automation as a routed system component An automation is documented as Record R00042 in the Automation Inventory table. Its health fields include expected interval, last started, last successful run, last failure, and current status. 165132617146.01.08.06.00042 Example route to Last Successful Run for Automation R00042 The Base Quest Center can run a health check against that route, produce a finding if the value is stale, and attach the exact table, field, automation, and permission context to the finding. 7.6 Organization base deletion request A Level 5 editor cannot delete the base. A Level 6 key holder cannot transfer organization ownership. A deletion request is routed to the protected-action process defined by the organization, such as Level 7 authorization plus one Level 6 approval and a delayed execution window. 8. Implementation Model and System Invariants The architecture is most reliable when each responsibility has its own table or service. The following data model separates declared intent, observed state, authorization, and history. 8.1 Recommended system tables Table Responsibility Base Registry Base marker, platform base reference, ownership mode, status, current runtime. Stack Inventory Stack markers, names, purposes, owners, diagram placement, active status. Table Inventory Table markers, parent stack, platform Table ID, current name, purpose, status. Field Inventory Field markers, platform IDs, current names and types, active status, timestamps. Record Registry Canonical record markers mapped to current platform Record IDs where stable routing is required. Component Inventories Interfaces, automations, scripts, views, forms, checks, and other system components. Permission Layouts Reusable groups of route-based permissions. Permission Rules Default and Override assignments, subjects, routes, levels, conditions, and effective periods. Ownership Registry Individual owners, organization owners, key holders, transfers, and versions. Permission Decision Log Explainable authorization results. Check Definitions Expected conditions and the algorithms that compare declared and observed state. Findings Discrepancies, errors, affected routes, severity, first seen, last seen, and resolution. 8.2 Declared, observed, and derived data Data class Examples Declared Canonical markers, descriptions, intended purpose, owner, expected type, expected use, permission policy. Observed Current platform IDs, names, types, active state, run timestamps, actual relationships, actual values. Derived Canonical routes, health status, effective permissions, discrepancies, diagram edges, unresolved mappings. Historical Prior names, retired markers, ownership transfers, decision logs, findings, and change events. 8.3 Self-inspection cycle Declare -> Observe -> Compare -> Route -> Decide -> Log -> Render The Base Quest Center can run each stage individually or on a schedule Stage Result Declare Creator defines the intended system, semantic markers, descriptions, ownership, and expected behavior. Observe Inventory scripts scan the live implementation and collect current state. Compare Checks identify differences between declared and observed state, alongside ordinary runtime errors. Route Every finding is attached to the exact canonical object or cell. Decide Permission engine determines who can inspect, change, approve, or destroy the affected object. Log Runs, decisions, changes, errors, and resolutions become structured records. Render Interfaces and the Base Network Diagram present the current system using stable canonical labels. 8.4 Permission enforcement boundary Model versus enforcement The permission structure defines the required authorization semantics. The implementation layer must enforce them at every read, write, interface, script, automation, API, export, and destructive action. Storing a rule in a table does not enforce it by itself. Permission administration must be protected separately from ordinary Level 5 editing. A user who can edit operational records must not automatically be able to edit the rules that determine their own access. 8.5 System invariants Canonical markers do not change because of rename, reorder, or visual movement. Platform IDs and names are never treated as the only canonical identity. Inventory scans do not overwrite human-authored descriptions or policy fields. Blank permission values mean inherit; Level 0 means explicit deny. More specific overrides win over broader overrides of the same precedence class. Direct subject overrides win over reusable layouts unless a protected policy explicitly states otherwise. Individual Bases always retain exactly one valid Level 6 owner. Organization Bases always retain at least one valid Level 7 authority. Lower permission levels cannot revoke Level 6 Individual ownership or Level 7 Organization ownership. Protected actions are not implied by ordinary Level 5 editing. Every ownership transfer is recorded and completed atomically. Every permission decision can be explained from the route and winning rules. Deleted markers remain historically resolvable and are not silently reused. Every finding identifies the most specific routable object available. 8.6 Migration and offline continuity The canonical map is the durable system specification. Airtable IDs and scripts are one implementation. During migration, export declared metadata, observed inventories, routes, permissions, ownership, checks, findings, and source code. Then map the same canonical routes to the new database and execution environment. Semantic specification -> Airtable runtime -> Offline runtime The canonical address and declared meaning remain stable while the execution layer changes 9. Glossary Term Definition Active Inventory state indicating that the object was observed during the current scan cycle. Base Top-level operational container in the canonical hierarchy. Base marker Twelve-digit semantic identifier assigned to a base in the ecosystem namespace. Base Network Diagram Visual representation of the current base network labeled with canonical markers. B-Perms Base-level permissions evaluated at the root of a route. Canonical map The declared, stable model of stacks, tables, fields, records, symbols, and relationships. Canonical marker Stable numeric label assigned to an object within its parent scope. Canonical route Semantic address composed from Base, Stack, Table, Field, and Record markers. Cell coordinate The intersection of one field and one record, represented by Field x Record. Component Inventory A table that represents interfaces, automations, scripts, views, forms, or other system components as records. Condition A dynamic test that refines a permission result based on current state. Declared metadata Human- or policy-authored description of intended meaning, use, ownership, and expected behavior. Default permission Baseline permission inherited from the nearest parent route when no more specific default is declared. Effective permission Final permission level after defaults, layouts, overrides, ownership, conditions, and protected-action rules are evaluated. Explicit denial Level 0 permission. It is a real rule and is not equivalent to a blank value. Field Typed property defined for records in a table. Field ID Current platform identifier for a field, such as an Airtable fld... ID. Field Inventory Observed metadata table containing one record per discovered field. Field marker Stable two-digit semantic reference for a field within a table. Finding Structured discrepancy or error attached to one or more canonical routes. First Seen Timestamp when an inventory first discovered an object. Full Editor Level 5 permission for direct ordinary operational editing. Individual Base Base whose final authority is one non-revocable Level 6 Base Owner. Inheritance Continuation of a parent permission or mapping when no local value replaces it. Inventory Key Composite Table ID and Field ID used to uniquely identify a field record in the Field Inventory. Key Holder Level 6 authority in an Organization Base, trusted with protected actions or approvals but subordinate to Level 7 ownership. Last Seen Most recent successful scan timestamp for an observed object. Level 0 No Access. Level 1 View Structure Only. Level 2 View Details. Level 3 Add Records without direct editing of existing records. Level 4 Suggest Edits through a proposal workflow. Level 5 Full Editor for ordinary operational data. Level 6 Individual Base Owner or Organization Base Key Holder, depending on ownership mode. Level 7 Organization Owner or full organizational authority. Observed metadata Facts collected from the current live implementation. Organization Base Base governed by Level 7 final authority and optional Level 6 key holders. Override Explicit exception that replaces inherited default permissions for a subject and route. Ownership mode Whether a base uses Individual or Organization authority semantics. Permission layout Reusable collection of route-based permission assignments. Platform ID Identifier assigned by the current runtime, such as tbl..., fld..., or rec.... Protected action High-impact operation requiring ownership or key-holder authority beyond ordinary editing. R-Perms Record-level permissions and exact-value restrictions. Record One instance or row in a table. Record marker Stable five-digit semantic reference for a record within a table. Retired marker Canonical marker preserved in history after the mapped object is removed. Route ancestry Ordered parent path from Base through Stack and Table to the target object. Route resolver Service that maps a canonical route to current platform objects and status. S-Perms Stack-level permissions inherited by descendant tables and components. Stack Canonical grouping layer above tables. Stack marker Stable two-digit semantic reference for a stack within a base. Suggest Edits Level 4 capability that creates a change proposal instead of directly mutating the target. System component Interface, automation, script, view, form, check, permission layout, or similar non-domain object represented as a record. T-Perms Table-level permissions, including field visibility and table operations. Table Structured collection of records governed by a shared field schema. Table ID Current platform identifier for a table, such as an Airtable tbl... ID. Table marker Stable two-digit semantic reference for a table within a stack. Unmapped Observed object that does not yet have a valid canonical mapping. Appendix A. Airtable Field Inventory Script This reference implementation creates and maintains one record for every field in the base. It excludes the Field Inventory table itself by default. The script updates observed metadata only; canonical marker and description fields may be added to the inventory table without being included in the update list. /* * AIRTABLE FIELD INVENTORY * * Creates and maintains one record for every field in the base. * * Behaviour: * - Creates a record when a new field is discovered. * - Updates names and types when tables or fields change. * - Marks deleted fields as inactive instead of deleting their history. * - Uses Airtable table and field IDs as stable identifiers. * - Excludes the Field Inventory table itself by default. */ const CONFIG = { inventoryTableName: "Field Inventory", // Change this to true if you also want to inventory the fields // belonging to the Field Inventory table. includeInventoryTable: false, // Airtable supports record operations in batches. batchSize: 50 }; // -------------------------------------------------- // Load and validate the inventory table // -------------------------------------------------- let inventoryTable; try { inventoryTable = base.getTable(CONFIG.inventoryTableName); } catch (error) { throw new Error( `Could not find a table named "${CONFIG.inventoryTableName}". ` + `Create the table or update CONFIG.inventoryTableName.` ); } // -------------------------------------------------- // Read existing inventory records // -------------------------------------------------- const inventoryQuery = await inventoryTable.selectRecordsAsync({ fields: [ "Inventory Key", "Table Name", "Table ID", "Field Name", "Field ID", "Field Type", "Active", "First Seen", "Last Seen" ] }); const existingRecordsByKey = new Map(); for (const record of inventoryQuery.records) { const inventoryKey = record.getCellValueAsString("Inventory Key").trim(); if (inventoryKey) { existingRecordsByKey.set(inventoryKey, record); } } // -------------------------------------------------- // Read the current base schema // -------------------------------------------------- const currentTimestamp = new Date().toISOString(); const currentFields = []; for (const table of base.tables) { const isInventoryTable = table.id === inventoryTable.id; if (isInventoryTable && !CONFIG.includeInventoryTable) { continue; } for (const field of table.fields) { currentFields.push({ inventoryKey: `${table.id}:${field.id}`, tableName: table.name, tableId: table.id, fieldName: field.name, fieldId: field.id, fieldType: field.type }); } } const currentInventoryKeys = new Set( currentFields.map(field => field.inventoryKey) ); // -------------------------------------------------- // Prepare record creations and updates // -------------------------------------------------- const recordsToCreate = []; const recordsToUpdate = []; for (const currentField of currentFields) { const existingRecord = existingRecordsByKey.get(currentField.inventoryKey); if (!existingRecord) { recordsToCreate.push({ fields: { "Inventory Key": currentField.inventoryKey, "Table Name": currentField.tableName, "Table ID": currentField.tableId, "Field Name": currentField.fieldName, "Field ID": currentField.fieldId, "Field Type": currentField.fieldType, "Active": true, "First Seen": currentTimestamp, "Last Seen": currentTimestamp } }); continue; } /* * Existing records are refreshed on every run. * * This catches: * - Renamed tables * - Renamed fields * - Changed field types * - Fields that were previously marked inactive and restored */ recordsToUpdate.push({ id: existingRecord.id, fields: { "Inventory Key": currentField.inventoryKey, "Table Name": currentField.tableName, "Table ID": currentField.tableId, "Field Name": currentField.fieldName, "Field ID": currentField.fieldId, "Field Type": currentField.fieldType, "Active": true, "Last Seen": currentTimestamp } }); } // -------------------------------------------------- // Mark fields that no longer exist as inactive // -------------------------------------------------- for (const [inventoryKey, existingRecord] of existingRecordsByKey) { const fieldStillExists = currentInventoryKeys.has(inventoryKey); if (fieldStillExists) { continue; } const currentlyActive = existingRecord.getCellValue("Active") === true; if (currentlyActive) { recordsToUpdate.push({ id: existingRecord.id, fields: { "Active": false } }); } } // -------------------------------------------------- // Batch-processing helpers // -------------------------------------------------- async function createRecordsInBatches(table, records, batchSize) { for (let index = 0; index < records.length; index += batchSize) { const batch = records.slice(index, index + batchSize); await table.createRecordsAsync(batch); } } async function updateRecordsInBatches(table, records, batchSize) { for (let index = 0; index < records.length; index += batchSize) { const batch = records.slice(index, index + batchSize); await table.updateRecordsAsync(batch); } } // -------------------------------------------------- // Write changes // -------------------------------------------------- await createRecordsInBatches( inventoryTable, recordsToCreate, CONFIG.batchSize ); await updateRecordsInBatches( inventoryTable, recordsToUpdate, CONFIG.batchSize ); // -------------------------------------------------- // Automation run results // -------------------------------------------------- output.set("fieldsFound", currentFields.length); output.set("recordsCreated", recordsToCreate.length); output.set("recordsUpdated", recordsToUpdate.length); output.set( "recordsMarkedInactive", recordsToUpdate.filter(record => record.fields?.Active === false ).length ); Appendix A.1 Test procedure 1. Test the scheduled trigger. 2. Test the Run a script action. 3. Open Field Inventory and confirm that one record exists for every field in every included table. 4. Confirm that output counts are plausible and that no duplicate Inventory Keys exist. 5. Rename a test field, rerun the script, and confirm that the existing record updates rather than duplicating. 6. Delete or temporarily remove a test field, rerun the script, and confirm that Active becomes unchecked. 7. Restore the field if appropriate and confirm reactivation when the same Field ID returns. Appendix B. Permission Resolution Pseudocode The following pseudocode describes the logical evaluation order. The actual runtime may store rules in Airtable, a local database, or another policy engine. function resolvePermission(subject, targetRoute, requestedAction) { const route = parseAndValidateRoute(targetRoute); const base = resolveBase(route.base); const ownershipMode = base.ownershipMode; const ownership = resolveOwnership(subject, base); const ancestry = buildRouteAncestry(route); const inheritedDefault = findNearestDefault(ancestry); const layoutRules = findAssignedLayoutRules(subject, ancestry); const directOverrides = findDirectOverrides(subject, ancestry); const winningRule = chooseMostSpecificRule({ inheritedDefault, layoutRules, directOverrides, ownership }); let effectiveLevel = winningRule?.level ?? 0; if (route.hasField && route.hasRecord) { const fieldLevel = resolveFieldAxis(subject, route); const recordLevel = resolveRecordAxis(subject, route); effectiveLevel = Math.min(effectiveLevel, fieldLevel, recordLevel); const cellOverride = findExplicitCellOverride(subject, route); if (cellOverride) { effectiveLevel = cellOverride.level; } } const conditionResults = evaluateConditions( subject, route, requestedAction, winningRule ); effectiveLevel = applyConditionResults( effectiveLevel, conditionResults ); const protectedActionResult = evaluateProtectedAction( subject, base, requestedAction, ownershipMode, ownership ); const decision = authorize( effectiveLevel, requestedAction, protectedActionResult ); writeDecisionLog({ subject, targetRoute, requestedAction, ownershipMode, inheritedDefault, winningRule, conditionResults, effectiveLevel, decision }); return decision; } Implementation note The pseudocode intentionally separates permission resolution from protected-action authorization. A Level 5 editor may be allowed to edit ordinary data while still being denied ownership transfer, legal-hold changes, permanent destruction, or root policy changes. End of architecture documentation