AI That Understands Context Before It Acts
CLADORA Intelligence is designed to resolve property, workspace, relationship, and authority context before proposing or coordinating actions through the platform’s canonical providers.
A Subordinate Orchestration Layer, Not a Canonical Truth Provider
In CLADORA’s platform design, artificial intelligence is neither a generic chatbot nor an unconstrained autonomous agent. It represents a governed assistive layer strictly subordinate to platform authority and human decision-making.
Not a Truth Provider
CLADORA Intelligence is designed as a subordinate orchestration layer and is not designated as a canonical truth provider. Identity, assets, general ledgers, bookings, and legal documents belong strictly to designated canonical providers.
No AI-Owned Canonical Write Path
The architecture does not designate CLADORA Intelligence as an independent writer of canonical platform truth. Consequential mutations are designed to pass through the responsible provider.
Subordinate to Authority
State-changing actions are designed to route through the relevant canonical provider rather than AI-owned truth stores. When authority cannot be proven, the architecture requires mutation denial.
From Spatial Context to Auditable Action Receipt
Every assisted interaction follows a structured architectural chain designed to reduce uncontrolled actions and preserve provider and authority boundaries:
Context Resolver
Designed to establish person identity, physical property demarcation, workspace boundary, role, and active mandate.
Intent Router
Interprets operational purpose and inquiry without conferring permissions (Intent is not Authority).
Authority Gate
Evaluates rights in CORE. If authority cannot be proven, the architecture requires mutation denial.
Planner
The planner model constructs an explainable, structured action plan verified step by step prior to dispatch.
Policy & Human Review
Consequential actions remain subject to applicable policy controls and appropriate human approval.
Canonical Provider
Routes authorized mutation proposals toward the designated canonical provider contract (FIN01, BK01, OPS, etc.).
Audit Receipt
The receipt model captures operational timestamps and decision context in the platform’s auditable event history.
Global Identity Is Insufficient: The Power of Scoped Context
In real estate operations, the same individual possesses distinct roles across properties. The Context Resolver architecture is designed to establish the relevant operational dimensions before consequential planning:
Person & Credentials
CORE identity and session context.
Workspace Scope
Workspace-scoped context designed to maintain separation between relevant property or organizational contexts.
Physical Asset & Demarcation
Exact building body, floor, demarcation, and specific spatial unit.
Occupancy Relationship
Owner, residential tenant, commercial occupant, technician, or guest.
Temporal Mandate
Active delegation boundaries, fiscal limits where configured, and time windows.
Country Pack
Jurisdictional context, terminology, workflow requirements, and statutory framework references (e.g. Romania baseline).
Domain Context
Applicable operational domain: AIRPROP, SERVICE, OPERATIONS, C&E, FINANCES.
Interpreting Purpose: Intent Does Not Confer Authority
The intent routing layer analyzes natural language inquiries and event triggers without mutating data and without assuming permission:
Informational Inquiries
Questions regarding property handbooks, quiet hours, or local municipal contacts.
Document Retrieval
Requests for technical inspection sheets, signed lease contracts, or association bylaws.
Service Requests
Initiating repair requests, cleaning tickets, or specialized service inquiries.
Technical Incidents
Reporting equipment malfunctions, leaks, or electrical failures to OPERATIONS.
Booking Intent
Checking availability for communal amenities and drafting reservations for BK01.
Financial Clarification
Inquiries regarding monthly maintenance quotas, utility splits, or invoices.
Mandate Verification and the Zero-Write Denial Standard
Before any plan is proposed or dispatched, the architecture interrogates CORE to evaluate legal authority in that specific property context:
Zero-Write Denial Standard
If required authority cannot be established in CORE, the architecture requires mutation denial.
Policy-Based Control Filtering
Where configured, actions are evaluated against financial spending caps, multi-signature thresholds, and applicable policy constraints.
Governed Human Approval
AI operates within verified authority boundaries. Consequential actions remain subject to applicable policy controls and appropriate human approval.
Step-by-Step Construction of Operational Proposals
The architecture defines a planner model designed to structure proposed operational steps without premature execution. An illustrative example of plan construction for a heating fault:
Context Resolution
Identifies Unit 4B, Building A, and confirms active residential tenant status.
Mandate Check
Verifies tenant authority to report internal heating anomalies.
Technical Context
Inspects thermostat model and recent equipment history from OPERATIONS.
Proposal Formulation
Drafts technical work order and proposes optimal maintenance time windows.
Designated Review
Presents structured proposal to tenant and designated reviewer for formal review where required.
Canonical Dispatch
Upon authorized confirmation, submits proposal to the canonical OPERATIONS provider.
Tool Routing Across Canonical Providers of Truth
The intelligence architecture defines no opaque backdoors. Domain responsibilities and proposed operations are designed to route strictly through canonical provider contracts:
Validates roles, workspace hierarchies, memberships, and voting/signing rights.
Retrieves canonical versions, archived contracts, and building technical logbooks.
Queries financial balances, explains expense allocations, and reviews invoices.
Checks schedule availability and applies capacity reservation rules.
Structures service requests, catalog specifications, and competitive RFQs.
Dispatches work orders, equipment instructions, and field technician tasks.
Emits notifications and logs multi-channel delivery receipts.
Synthesizes sales inquiries, pre-sales contracts, and lease transitions.
Assembles spatial handbooks, community notice boards, and arrival guidance.
Assistive Recommendation vs. Canonical State Mutation
To preserve platform integrity, the architecture strictly distinguishes between informational output and transactional mutation:
Assistive Recommendation
Zero State Mutation (Read-Only / Draft Proposal)Explaining a utility charge variance, comparing three contractor bids, proposing available reservation slots.
Proposed Canonical Action
Proposed State Mutation (Where Supported and Authorized)Proposing a work order in OPERATIONS, proposing a payment record in FIN01, proposing a reservation in BK01.
Conversational Plan Modification Respects Authority Boundaries
A user may suggest refining an operational proposal through conversational instructions (“Use the second provider instead”, “Reschedule for Tuesday”, “Notify only the manager”). The architecture requires context, authority, and applicable policy to be re-evaluated before a consequential modification can be proposed or dispatched.
Architectural Conditions for Human Handoff and Clarification
The architecture defines human handoff or clarification conditions for situations such as:
Ambiguous authority or conflicting multi-role mandates in the active workspace.
Missing cadastral or spatial demarcation linking requester to the physical asset.
Financial transaction values exceeding established configured policy thresholds.
Requests touching life-safety or safety-sensitive systems (natural gas, elevators, fire detection).
Conflicting documentary evidence or unverified ownership certificates.
Explainability and Decisional Transparency Model
For consequential recommendations or actions, the architecture defines a transparency model designed to surface questions such as:
Exact synthesis of the user inquiry extracted from dialogue.
Precise cadastral demarcation and organizational scope.
Active role (owner, tenant, etc.) verified in CORE.
Specific API payload intended for the canonical provider.
Designated authority (SERVICE, OPERATIONS, FIN01, BK01).
Specific policy ceiling or risk threshold triggering the review.
Auditable Action Receipts and Event History Model
The architecture defines an auditable receipt model intended to capture request context, CORE authority decisions, applicable approvals, and provider execution outcomes in the platform’s auditable event history.
Representative Intelligence Composition Scenarios
The workflows below illustrate conceptual architectural compositions showing how AI is designed to coordinate with canonical providers (not universal runtime guarantees):
Scenario A: Resident Heating Malfunction Inquiry
Residential Living / TenantContext: Unit 4B → Intent: Radiator leak reported → Authority: CORE checks tenant role → Plan: Diagnostic guidance + draft work order → Review: Subject to tenant confirmation → Provider: Routed to OPERATIONS → Receipt: Proposed action logged in audit history.
Scenario B: Property Manager Maintenance Cost Inquiries
Commercial Operations / ManagerContext: Central Tower HOA → Intent: Why did cold water costs spike? → Authority: CORE verifies manager mandate → Plan: Queries meter histories & tariffs from FIN01 → Output: Comparative variance report → Zero Mutation: General ledger remains untouched.
Scenario C: Communal Terrace Booking for Community Event
Community Experience / OwnerContext: Rooftop Terrace Building B → Intent: Reserve for Saturday evening → Authority: CORE checks owner role → Plan: BK01 checks schedule & quiet-hour rules → Review: Owner accepts house rules → Provider: Routed to BK01 for official reservation.
Scenario D: Subleasing Clause Clarification
Commercial Lease / Tenant CFOContext: Innovation Hub, 3rd Floor → Intent: Can we sublease 200 sqm? → Authority: CORE validates tenant signing mandate → Plan: Queries lease agreement in VAULT → Output: Explanatory summary citing relevant clauses without providing legal advice.
Scenario E: Field Contractor Completion Sign-Off
Operational Maintenance / ContractorContext: Basement Pump Station → Intent: Pump overhaul complete → Authority: CORE validates technician access pass → Plan: Verifies checklist completion → Provider: Dispatched to chief engineer in OPERATIONS → Receipt: Time-stamped sign-off logged.
How Intelligence Assists Each Platform Domain
Illustrative assistance patterns showing how intelligence is designed to coordinate with each domain without assuming canonical ownership:
Illustrative assistance patterns for synthesizing commercial inquiries and drafting leasing documentation; AIRPROP remains the canonical owner of transaction lifecycles.
Assistance models for structuring service requests and organizing bid comparisons; SERVICE remains the canonical service-order provider.
Assistance models for interpreting fault reports and drafting technician dispatches without autonomous equipment diagnosis; OPERATIONS remains the canonical work-order provider.
Assistance models for drafting contextual arrival handbooks and community announcements; C&E remains the canonical experience provider.
An intelligence interaction may explain provider-derived financial context where authorized, without autonomous billing or ledger writes; FIN01 remains financial truth.
Booking intent is architecturally routed toward BK01, which remains the canonical owner of availability and capacity truth.
Authorized document assistance may retrieve or summarize relevant content while DOCUMENTS remains canonical; an AI summary does not substitute for the canonical document.
Strictly Enforced Architectural Safety Boundaries
To prevent operational risks and overclaims, the CLADORA architecture defines 5 strict governance principles:
AI Does Not Create Rights
Intelligence cannot create ownership, workspace membership, legal mandates, or financial allocations.
AI Does Not Bypass Providers
There are no shadow AI databases. All operations transact strictly through canonical provider contracts.
Exclusion of Safety-Critical Control
The platform does not autonomously operate natural gas valves, elevators, fire suppression, electrical gear, or hardware locks.
Model and Vendor Neutrality
The target orchestration architecture is designed to avoid coupling canonical platform truth to a single model vendor.
Data Minimization and Privacy Design
Intelligence is designed around workspace-scoped context, authority-bounded retrieval, and data-minimization principles.
Architecture Maturity and Release Governance
Our public documentation outlines the comprehensive architectural model of CLADORA Intelligence. In real-world enterprise deployments, capability availability is governed individually by product release roadmaps and customer implementation scope:
Architect Governed, Context-Aware Intelligence for Your Assets
Connect with CLADORA platform architects to explore how governed intelligence can assist operational teams while preserving transactional integrity.