2 - CERBERUS_Base_Service_Structural_Integrity_Architecture_v0.1.docx

CERBERUS Base Service Architecture Canonical Schema Coordinates, Five-State Structural Diagnostics, and Automated Base Maintenance ARCHITECTURE THESIS A self-describing Base contains enough structural information to inspect itself. By comparing registered contracts against observed runtime structure, CERBERUS can locate exact structural defects, classify their integrity consequence, derive service work, and confirm repair without requiring probabilistic semantic inference. Architecture Paper v0.1 Bootstrap Candidate | August 2026 Abstract This paper defines CERBERUS BASE SERVICE: a structural integrity and maintenance architecture for a self-describing Base. The architecture treats the Base Registry, Table Registry, Field Registry, linked-field topology, object contracts, and other registered structural expectations as an executable maintenance specification. A compact canonical coordinate grammar identifies Tables by letter and Fields by number, allowing relationships such as A12 → G41 to name exact schema edges independently of Airtable table IDs, field IDs, or view order. BASE SERVICE compares declared structure against observed runtime structure, creates deterministic diagnostic findings, classifies each finding through a five-state language—Forbidden, Fix, Warning, Okay, and Ideal—and derives service work from those findings. Severity is contextual rather than based on raw field completeness: a missing Formula relationship may invalidate computation while an absent optional Family link may only reduce descriptive completeness. Diagnostic locality preserves the exact source of a defect, while dependency impact may propagate separately to downstream structures. Service completion is established by repair of canonical data followed by reinspection, not by manually closing an alert. The resulting system is a native maintenance layer for CERBERUS rather than a generic database-cleanup tool. It can summarize health upward from Field contract to Record, Table, Stack, and Base while preserving exact drill-down to the original failing coordinate. Airtable can host a reference implementation through Registry records, linked fields, inspection scripts, and service views, but the diagnostic grammar and contracts remain platform-independent. Cross-Base federation, Home Base reporting, Base Crawlers, and recursively distributed service are intentionally reserved for subsequent architecture papers. Keywords: Base Service, structural integrity, canonical schema coordinate, diagnostic contract, self-describing Base, maintenance, service queue, deterministic diagnostics, Airtable, CERBERUS Document Map Sections Focus 1–4 Purpose, self-description, canonical schema coordinates, and platform independence 5–8 Diagnostic contracts, five-state integrity, contextual severity, and diagnostic classes 9–12 Locality, dependency impact, recursive rollup, integrity metrics, and the service cycle 13–16 Repair authority, AI boundary, Airtable implementation, and version-aware evaluation 17–18 Conformance scenarios, design laws, non-goals, and Bootstrap implications 1. Purpose and Scope CERBERUS BASE SERVICE defines how one registered Base can inspect and maintain its own structure. The paper assumes that the Base is already self-describing: Tables, Fields, object identities, links, and important structural expectations are represented in governed Registries or equivalent contracts. BASE SERVICE does not invent those expectations. It reads them, compares them with the current implementation, and reports the difference. The architecture is deliberately structural. It is concerned with whether a required relationship exists, whether a target is the correct type, whether cardinality is valid, whether a canonical structure agrees with its registered contract, and whether a dependency is available. It is not a generic measure of how much text or metadata happens to be populated. A record can be small and Ideal; another can contain hundreds of populated fields and still be Forbidden because one critical contract is violated. 1.1 Core terms Term Definition Declared Base The canonical structure and expectations registered for the Base: Tables, Fields, contracts, identities, relationships, and applicable Rules. Observed Base The current runtime state actually present in the implementation. Diagnostic Contract A registered test stating where it applies, what should be true, and how failure is classified. Diagnostic Finding The evidence produced when observed structure is evaluated against an applicable Diagnostic Contract. Integrity State One of Forbidden, Fix, Warning, Okay, or Ideal. Service Item Derived maintenance work produced from a diagnostic finding when intervention is warranted. Service Priority A separate ranking of when service should be addressed, considering operational impact as well as integrity state. 1.2 Boundaries This paper intentionally stops at the boundary of one Base. It does not define Stack-to-Base expansion, Home Base federation, Base Crawlers, local SOLAR handoff, BOOTSTRAP handoff, or cross-Base service reporting. Those mechanisms depend on the local integrity architecture defined here and are treated separately. 2. From Self-Description to Self-Service A self-documenting system has an unusual maintenance advantage: its own architecture can become the specification against which its runtime health is measured. If the Registry says a computational BitGroup requires one Formula link, the absence of that link is not an interpretive opinion. It is a structural discrepancy. If a canonical identity must be unique and two active records claim it, the conflict is equally observable. BASE SERVICE therefore begins with a simple comparison: declared structure versus observed structure. The declared side represents what the Base says should be true under an applicable contract. The observed side represents what is actually true in the implementation. A mismatch produces a Diagnostic Finding at the exact structural location where the mismatch occurs. SERVICE PRINCIPLE The Base is the source of truth; service is a derived view of whether the Base currently conforms to its own registered contracts. Figure 1. Self-description becomes self-service when registered expectations are compared deterministically with current runtime structure. The same mechanism can identify healthy state. A contract that passes contributes evidence toward Okay or Ideal integrity. Consequently, BASE SERVICE is not only an error detector. It is a structured health model capable of explaining why an object is valid, incomplete, degraded, or invalid for a particular use. 3. Canonical Schema Coordinates The diagnostic system requires a compact way to name the schema it is inspecting. CERBERUS assigns each canonical Table a letter according to its stable Table Registry position and each canonical Field a number according to its stable Field Registry position. The resulting coordinate is human-readable, machine-addressable, and independent of runtime identifiers. The basic form is Table Letter + Field Number. A12 means canonical Table A, canonical Field 12. A structural edge is written as a relationship between coordinates: A12 → G41. The meaning is not merely that two records happen to be linked; it identifies the exact schema relationship whose integrity is being evaluated. Figure 2. Canonical schema coordinates identify Tables by letter and Fields by number; A12 → G41 names an exact registered relationship. 3.1 Minimal coordinate grammar Form Meaning Example A12 One canonical Field location Inspect or refer to Table A, Field 12. A12 → G41 One directed structural relationship Evaluate the expected edge from A12 to G41. A12 → G41 → C7 A bounded dependency path Trace a diagnostic or dependency through several exact schema locations. The coordinate describes schema, not a particular record instance. A diagnostic finding carries the record identity separately. This keeps the schema language compact while still allowing a finding to resolve to one exact record, field, and relationship in the Base. 3.2 Canonical order Coordinates must derive from canonical Registry order, not from a mutable Airtable Grid view. Reordering fields for a convenient human view must not silently change A12 into A19. Once a coordinate is published within a contract version, it remains stable for that version. Retired positions should be deprecated or reserved rather than reassigned to unrelated semantics when historical diagnostic traceability matters. 4. Coordinate Stability and Platform Independence Airtable table IDs and field IDs are implementation addresses. They are useful to scripts, but they are not suitable as the conceptual diagnostic language of CERBERUS. A canonical coordinate can bind to those runtime IDs underneath the Registry while preserving a stable semantic address above them. Figure 3. The same CERBERUS schema coordinate can bind to Airtable today and to another runtime later without changing the diagnostic contract. This separation also simplifies migration. If a Table moves, a Field is recreated, or the Base is compiled into another platform, the Registry updates the implementation binding while the canonical contract can continue to refer to A12 → G41. Runtime rebinding is therefore distinct from semantic renaming. 4.1 Coordinate versioning Schema stability does not require the Base to stop evolving. Instead, coordinate meaning is evaluated within the applicable contract version. New Tables and Fields can extend a contract, while breaking changes can publish a new version. Historical findings remain interpretable because their coordinates are read against the version under which they were produced. 5. Diagnostic Contracts A Diagnostic Contract is the reusable inspection primitive of BASE SERVICE. It does not describe one record. It describes what must, may, or must not be true at a canonical schema location for every record to which the contract applies. This moves diagnostic metadata to the schema level rather than multiplying it across every record instance. 5.1 Minimum contract anatomy Component Question answered Source Where does inspection begin? Target What exact target or target class is expected, if any? Applicability condition Under what object state or role does this contract apply? Expectation What must be true: presence, cardinality, type, structure, consistency, or another registered condition? Failure state What integrity state should be emitted when the expectation is violated? Figure 4. A compact Diagnostic Contract can inspect every applicable record while keeping the expectation itself registered only once. For example, a contract may state that B12 must resolve to C1 exactly once whenever the source record is a computational BitGroup. The diagnostic engine applies the contract to every qualifying BitGroup, reads the observed relationship, and emits a Fix finding when zero targets exist or a Forbidden finding if a prohibited target type is linked, depending on the contract design. 5.2 Contract Registry A dedicated Diagnostic Contract Registry is justified when expectations become numerous enough that embedding them directly into the Field Registry would make the Field Registry harder to reason about. The contract record can remain small: source, optional target, applicability, expectation, and failure state. Additional metadata should be added only when it carries genuinely new diagnostic information. 6. Five-State Integrity Model The original service vocabulary can be reduced to five states by separating structural health from the reason for service and from the action taken next. Guided repair, cleanup, and anomaly review remain useful capabilities, but they do not need to be independent integrity levels. State Meaning Typical operational response Forbidden A canonical contract is violated in a way that makes the affected use invalid. Fail closed for the affected governed operation until the violating condition is repaired or explicitly superseded. Fix A definite defect or required omission exists. The requirement is known. Create or surface service work; provide guided repair when sufficient information exists. Warning The structure remains usable for its declared role, but a known deficiency, anomaly, deprecation, or cleanup condition deserves attention. Continue operation where permitted; schedule review or maintenance according to priority. Okay All requirements necessary for the object’s declared role are satisfied. Normal operation. Optional improvements may still exist. Ideal All applicable required and preferred integrity conditions are satisfied. No known applicable service improvement is currently identified. Figure 5. The five-state language is compact enough for Base-wide display while preserving a meaningful distinction between invalid, defective, degraded, valid, and fully satisfied structures. 6.1 Precedence A simple categorical precedence can resolve an object’s local integrity: any applicable Forbidden violation yields Forbidden; otherwise any Fix violation yields Fix; otherwise any Warning condition yields Warning; otherwise the object is Okay; and it becomes Ideal when all applicable preferred conditions are also satisfied. This precedence is more meaningful than averaging states together. 6.2 State is not a score Forbidden does not mean “0 percent complete,” and Ideal does not mean “100 percent of every field populated.” The state describes the strongest applicable structural consequence. Quantitative ranking, if useful, belongs in a separate Integrity Index and service-priority model. 7. Contextual Integrity and Minimum Sufficiency Field completeness alone is a poor measure of integrity because different objects exist to satisfy different contracts. A Symbol with a glyph but no registered meaning may be severely deficient because semantic interpretation is central to that object. A BitWord with complete Bits, BitGroups, Reader, and computational contracts may remain functionally valid even if a preferred Family relationship has not yet been assigned. Figure 6. Context determines severity: visually similar blank fields can produce very different service states because the object contracts are different. 7.1 Minimum Sufficiency An object is Okay when the information and relationships required for its declared role are satisfied. It is not penalized for fields that do not apply. This makes BASE SERVICE compatible with bounded, specialized Tables and prevents a universal “fill everything” mentality from becoming an architectural requirement. 7.2 Anti-bloat interpretation of Ideal Ideal means that all applicable required and desirable conditions are currently satisfied. It does not reward redundant metadata. If a value is already deterministically recoverable from canonical structure, duplicating it elsewhere should not improve integrity and may instead create a redundancy diagnostic. The service architecture therefore reinforces the broader CERBERUS principle of storing each authoritative fact where it belongs. CONTEXTUAL INTEGRITY LAW The significance of missing or conflicting information is determined by its role in the applicable object contract, not merely by the visual fact that a field is empty. 8. Diagnostic Classes Integrity state answers how serious a condition is. Diagnostic class answers what kind of structural question produced the condition. Keeping these dimensions separate allows one five-state language to describe many kinds of faults without proliferating status categories. Class Primary question Example Presence Is required information present? A required Reader link is blank. Relationship Does the expected edge exist? A BitGroup does not resolve to its registered Formula. Cardinality Are there the correct number of targets? A one-to-one contract resolves to three targets. Type Does the relationship terminate at the correct object class? A Formula field links to a non-Formula object. Consistency Do structures that should agree actually agree? Reader Formula does not agree with the BitGroup Formula contract. Structure Is ordering, width, nesting, or composition valid? A BitWord placement violates its registered specification. Dependency Is a required dependent structure available? An otherwise valid object depends on an unavailable computational component. Lifecycle Is status usage valid? A Deprecated object is used where only Active is permitted. Orphan Is an unexpected disconnection present? A registered object is unattached when the contract requires ownership. Redundancy Is duplicate or obsolete ownership competing with canonical data? A copied field is being maintained beside the canonical source. Figure 7. Diagnostic classes describe the kind of structural test without becoming additional integrity states. 9. Diagnostic Locality and Dependency Impact At large scale, diagnostics become unusable if one originating defect is copied as a local failure onto every dependent record. BASE SERVICE therefore distinguishes the location of the violated contract from the downstream impact caused by that violation. If SCALAR-6 is missing a Formula contract and fifty BitWords depend on SCALAR-6, the local defect belongs to SCALAR-6. A dependent BitWord whose own construction is perfect should not be reported as locally malformed merely because a dependency has become degraded. Instead, the BitWord can carry or derive a dependency-impact state that points back to the originating finding. Figure 8. Diagnostic locality preserves one originating fault while allowing downstream operational impact to propagate through dependency relationships. 9.1 Why locality matters Locality prevents service inflation. Without it, one missing Formula could generate thousands or millions of apparently independent Fix records. With locality, CERBERUS can say “one local Fix, 12,481 affected dependents.” This is both more accurate and more useful for prioritization because repairing one source defect can clear a large downstream impact surface. DIAGNOSTIC LOCALITY LAW A defect is attributed to the exact contract location where observed structure violates declared structure. Downstream impact may propagate without duplicating the originating defect. 10. Recursive Service Rollup BASE SERVICE should be readable at the same nested resolutions used elsewhere in CERBERUS. Exact findings occur at Field or relationship contracts, but humans often begin at the level of a Table, Stack, or entire Base. The service system therefore rolls summaries upward while preserving exact drill-down downward. Figure 9. Service status can summarize upward from exact schema coordinates while retaining a deterministic path back to the originating contract. 10.1 Rollup dimensions A rollup can expose at least two distinct views. The first is the operating state of the structure’s required contract: whether the Table, Stack, or Base can currently perform the governed functions expected of it. The second is the service inventory: counts and categories of Forbidden, Fix, Warning, Okay, and Ideal findings or objects inside that scope. The whole Base should not automatically become Forbidden merely because one isolated experimental record contains a Forbidden finding. A useful Base-level view can instead report “Operating State: Okay” while separately showing “2 Forbidden findings, both isolated experimental.” Contract impact and inventory are related but not identical. 10.2 Exact drill-down Every rollup should be reducible back to exact evidence. A user who sees “BOSS Stack: Warning” should be able to descend to the affected Table, Record, Field, and coordinate such as A12 → G41. Summary must never destroy provenance of the underlying diagnostic result. 11. Integrity State, Integrity Index, and Service Priority The five integrity states are intentionally categorical. Large Bases may additionally benefit from quantitative ranking, but several questions must remain separate: what kind of condition exists, how well the object satisfies its applicable contract overall, and how urgently the service work should be addressed. Dimension Question Example output Integrity State What is the strongest applicable structural consequence? Fix Integrity Index How completely does the object satisfy its applicable contracts? 94% or another normalized score Service Priority How soon should the service work be handled? Critical / High / Medium / Low, or another governed priority scale Figure 10. Service priority may be high even when a local integrity defect is small, because dependency reach and operational use can dominate urgency. 11.1 Integrity Index If an Integrity Index is implemented, it should measure satisfaction of applicable Diagnostic Contracts rather than percentage of populated fields. Contract weighting may eventually distinguish critical structural obligations from minor preferred conditions, but the exact scoring formula should remain an implementation choice until sufficient real diagnostic data exists to validate it. 11.2 Priority by graph impact Service Priority can incorporate factors such as integrity state, dependency reach, active usage, operational criticality, whether the issue blocks other repairs, and confidence that a repair is known. A single Fix affecting a central Formula used by thousands of structures may rationally outrank many low-impact Warnings. 12. Automatic Service Cycle and Service Findings Once contracts are machine-readable, a Base can be tagged for service automatically. The diagnostic engine periodically or conditionally inspects applicable structures, produces findings, classifies them, ranks service work, and returns after repair to verify that the Base now conforms. Figure 11. The service cycle is continuous: inspect, find, classify, prioritize, repair, and reinspect canonical state. 12.1 Derived service items A service item is a work representation derived from a finding. It can contain the object identity, exact schema coordinate, expected condition, observed condition, integrity state, downstream impact, and repair guidance. The maintenance record does not become the authoritative truth about whether the problem still exists. Service field Example Finding SRV-000481 Object SCALAR-6 Coordinate B12 → C1 Integrity State Fix Observed 0 Formula links Expected Exactly 1 valid Formula target Dependency Impact 83 downstream structures Repair Guidance Select or restore a compatible registered Formula Verification Re-run DC-017 after mutation 12.2 Service queue behavior The service queue should be generated from current findings rather than manually curated as a parallel truth system. Resolved findings can be retained historically for provenance, but the current service view is determined by current canonical evidence. This allows the Base to heal without requiring a human to remember to update multiple administrative records. 13. Repair the Source: Reinspection and Mutation Authority A maintenance interface can easily create a dangerous illusion: a user marks an alert “Resolved” while the canonical defect remains untouched. BASE SERVICE explicitly rejects that model. Repair is applied to the source structure; the diagnostic engine then re-evaluates the relevant contract. Passing reinspection is the evidence that the service condition is resolved. Figure 12. Repairing canonical state and passing reinspection resolves a finding; changing the alert alone does not. 13.1 Detection authority is not mutation authority A diagnostic engine may be authorized to read a wide portion of the Base while having no authority to mutate it. Discovering that a required Formula link is missing does not itself grant permission to create or change that link. Repair must travel through the same governed Rules, Operators, permissions, or human approvals that normally control canonical mutation. 13.2 Guided repair A Fix finding can still be highly actionable. If the contract and linked context constrain the repair sufficiently, BASE SERVICE can present the exact target field, expected target class, compatible candidates, and reason the relationship is required. Some repairs may eventually be safe for deterministic automation; others should remain proposals or guided human actions. The integrity architecture does not need to decide that policy globally. REPAIR RULE Repair the source, not the alert. A repair is complete only when the applicable canonical diagnostic contract passes reinspection. 14. Deterministic Diagnostics and the AI Boundary BASE SERVICE follows the same architectural preference as deterministic BitWord compilation: do not ask AI to infer what explicit structure can already establish. If a contract says A12 must resolve to G41 exactly once and the observed value is null, the detection problem is a comparison, not a semantic judgment. Figure 13. The structural engine determines whether explicit contracts pass; AI may optionally assist with explanation, summarization, comparison, and guided repair after a finding exists. 14.1 Appropriate AI roles Explain why a finding matters in domain language. Summarize service conditions across a large Table or Stack. Compare candidate repairs when several valid structural options exist. Draft missing human-facing semantic information where the diagnostic has already identified the gap. Guide a user through a repair procedure while preserving mutation authority. AI assistance is therefore layered above deterministic evidence. This reduces hallucination risk, makes service findings reproducible, and permits the diagnostic engine to run at machine scale even when no language model is available. 15. Airtable Reference Implementation Airtable can host a practical reference implementation using the structures CERBERUS already maintains. The Table Registry identifies canonical Tables and runtime table IDs; the Field Registry identifies canonical Fields and runtime field IDs; a Diagnostic Contract table stores reusable inspection rules; scripts or automations evaluate records; and service views expose the resulting findings. Figure 14. Airtable can implement the architecture with Registry records, contract records, deterministic inspection scripts, service findings, and human-facing service interfaces. 15.1 Compact implementation pattern Component Responsibility Table Registry Canonical Table identity, canonical order, runtime table binding. Field Registry Canonical Field identity, canonical order, runtime field binding. Diagnostic Contract Registry Source coordinate, optional target, applicability, expectation, failure state. Inspection Engine Reads applicable contracts and observed records; emits deterministic findings. Service Findings Derived current/history records tied to exact source evidence. Base Service Interface Views by integrity state, priority, Table, Stack, object, or diagnostic class. The crucial scaling property is that the diagnostic contract is stored once and applied many times. A Table with ten million records does not need ten million copies of “this field must link to one Formula.” The schema-level contract and one generic inspection engine can evaluate every applicable record. 15.2 Runtime independence Airtable is the current implementation substrate, not the semantic definition of BASE SERVICE. The same canonical coordinates and contracts could later compile into SQL constraints, a native graph runtime, background validation services, or other storage systems. Only the implementation bindings and inspection adapter need to change. 16. Version-Aware Diagnostic Evaluation Schema evolution creates a predictable diagnostic hazard: a newly introduced requirement can make older valid records appear defective if the engine blindly evaluates everything against the newest contract. BASE SERVICE therefore evaluates a structure against the contract version applicable to that structure. Figure 15. Older structures remain valid against their applicable contract version; migration to a newer contract is a separate governed service operation. 16.1 Migration is not retroactive failure If contract v2.0 adds a new required Field, a v1.0 record does not become historically malformed merely because v2.0 now exists. The system may create migration work if policy requires upgrading the record, but that is different from claiming the record violated its original contract. Version-aware evaluation preserves historical integrity and makes upgrade policy explicit. 16.2 Diagnostic history Findings should retain the contract version used for evaluation. This allows later reconstruction of why a record was classified as Fix or Warning at a particular time, even after the Base schema has evolved. A diagnostic history without version context is not reliably interpretable. 17. Conformance Scenarios The following scenarios summarize the intended behavior of the architecture. They are illustrative conformance cases rather than exhaustive implementation tests. Scenario Observed condition Expected result Required Formula missing Computational BitGroup has zero Formula targets. Fix at the exact Formula contract coordinate; dependent structures receive impact, not duplicate local Fixes. Wrong Formula target type Formula field resolves to an object outside the permitted target class. Forbidden for the affected computation if the contract declares incompatible targets invalid. Preferred Family absent Operational BitWord satisfies all computational requirements but lacks a preferred Family relationship. Warning or Okay according to the applicable contract; never penalize as if computation were broken. Sparse but complete object Object populates only the fields required for its declared role. Okay; Ideal if no applicable preferred condition remains. Redundant copied metadata A derived value is independently stored and can drift from canonical ownership. Warning under a redundancy/cleanup diagnostic; do not reward extra population. One fault, many dependents Central reusable object violates one local contract and thousands depend on it. One local defect plus propagated impact references; service priority may rise with dependency reach. Alert manually closed Service record is marked resolved while source contract still fails. Finding remains open or is regenerated; canonical evidence controls current state. Source repaired Canonical structure is corrected and the relevant contract passes reinspection. Service finding resolves; downstream impacts recalculate. Old object under old contract v1.0 record passes v1.0 while v2.0 introduces new requirements. Pass under v1.0; optional migration service may be created separately. AI unavailable All explicit structural contracts remain machine-readable. Deterministic diagnostics continue to function; only optional explanation/assistance is unavailable. 18. Design Laws and Bootstrap Implications BASE SERVICE can be summarized as a small set of architectural laws. These laws are intended to remain stable even if the current Airtable implementation changes. Law Statement Declared Structure Law A diagnostic expectation originates from a registered canonical contract. Schema Coordinate Stability Law Published diagnostic coordinates refer to stable canonical Registry positions rather than mutable platform display order. Exact Diagnostic Law Every structural finding resolves to an exact canonical object, field, relationship, or contract. Contextual Integrity Law The significance of missing or conflicting information is determined by its role in the applicable object contract. Minimum Sufficiency Law Objects are not penalized for absent information that their declared role does not require. Anti-Bloat Law Ideal integrity means all applicable conditions are satisfied, not that every available field is populated. Diagnostic Locality Law A fault belongs to the precise contract location where declared and observed structure disagree. Impact Propagation Law Dependency impact may propagate without duplicating the originating defect. Severity–Priority Separation Law Structural integrity state and service priority are distinct properties. Derived Service Law Service findings derive from canonical state and do not supersede it. Mutation Authority Law Detection of a structural fault does not itself authorize mutation. Reinspection Law A repair is complete only when the affected canonical contract passes subsequent inspection. Deterministic Detection Law Explicit structural contracts are evaluated deterministically rather than through probabilistic semantic inference. Version Applicability Law A structure is evaluated against the contract version applicable to that structure; migration is separate from retroactive failure. 18.1 Bootstrap value For BOOTSTRAP, this paper establishes a compact way for an AI or human to understand the health of a Base before working deeply inside it. A service summary can indicate which structures are trustworthy, which have known deficiencies, which operations are forbidden, and where exact repairs are required. Because the findings are structural, the same health information can be consumed by interfaces, scripts, AI systems, or future runtimes without rewriting the diagnostic logic in natural language. 18.2 Reserved extensions The local service architecture is intentionally complete before federation is introduced. Two subsequent papers extend it without changing the diagnostic primitives defined here. Reserved paper Extension Paper 2 — Expanding Bases, Data Contracts, and Base Crawler Defines how large Stacks externalize into independent Bases, preserve bounded data contracts, link directly to Home, and use a compact crawler to route into each Base’s local SOLAR and BOOTSTRAP. Paper 3 — Federated Self-Service Architecture Combines local BASE SERVICE with distributed Bases so each Base services its own interior and reports bounded contract health to Home without exporting its entire maintenance graph. 18.3 Conclusion BASE SERVICE converts CERBERUS self-description into an operational maintenance capability. Canonical schema coordinates make faults addressable, Diagnostic Contracts make expectations executable, the five-state language makes health readable, and reinspection keeps service grounded in canonical evidence. The architecture scales because expectations are registered once at the schema level and applied repeatedly to the records that instantiate them. CLOSING PRINCIPLE CERBERUS does not need a separate maintenance theory imposed from outside. Once the Base explicitly declares what its structures are supposed to be, that self-description can become its maintenance manual, diagnostic language, and service map.