Section 101 of 102
PART VII — Development, Verification, Certification & Governance
Stable section ID: S05-CON-010-SECTION-101 · 587 content blocks
113. AI Agent Development Framework and SDK
System05 should provide an AI Agent Development Framework and SDK for creating interoperable, testable, secure, and governable agents.
The framework may provide:
- Agent templates.
- Standard manifests.
- Identity and authentication libraries.
- Building BIOS APIs.
- Digital Twin APIs.
- BDL and Compiler interfaces.
- Event schemas.
- Command schemas.
- Permission models.
- Evidence structures.
- Logging utilities.
- Simulation tools.
- Test fixtures.
- Safety-envelope definitions.
- Human-approval components.
- Packaging and signing tools.
The SDK shall encourage developers to separate:
- Reasoning from execution.
- Recommendations from commands.
- Agent permissions from tool permissions.
- Observed facts from inferred conclusions.
- Approved configuration from proposed configuration.
- Model behavior from deterministic safety logic.
The framework should support multiple model providers, deployment environments, programming languages, and tool ecosystems where practical.
Use of the SDK shall not itself establish conformance or certification. Developers remain responsible for demonstrating that the completed agent satisfies the requirements applicable to its intended functions.
114. Agent Interface Protocol
The Agent Interface Protocol shall define how agents communicate with System05 services, tools, humans, equipment, and other agents.
The protocol should define:
- Agent identity.
- Session identity.
- Message identity.
- Sender and recipient.
- Message type.
- Building and project scope.
- Component or zone scope.
- Timestamp and expiration.
- Schema version.
- Authority basis.
- Requested action.
- Evidence references.
- Confidence.
- Required response.
- Error behavior.
- Audit requirements.
Message types may include:
- Observation.
- Query.
- Response.
- Proposal.
- Recommendation.
- Approval request.
- Approval decision.
- Command request.
- Command.
- Acknowledgment.
- Execution result.
- Verification result.
- Warning.
- Incident.
- Revocation.
- Status update.
The protocol shall prevent a descriptive message from being interpreted as an executable command unless it satisfies the required command structure and authorization checks.
Backward compatibility, deprecation, retry behavior, duplicate detection, message ordering, timeout, and partial failure shall be defined.
Natural-language communication may supplement the protocol but shall not replace structured information required for consequential actions.
- 115. Agent Package Format and Distribution
- Every distributable System05 agent should be represented by a defined Agent Package.
An Agent Package may contain:
- Agent manifest.
- Agent identity information.
- Provider information.
- Intended functions.
- Declared capabilities.
- Prohibited functions.
- Required permissions.
- Required tools.
- Supported System05 versions.
- Model and software dependencies.
- Data requirements.
- Safety Envelope.
- Test results.
- Conformance status.
- Certification status.
- Installation instructions.
- Update and rollback information.
- Privacy disclosures.
- License and support terms.
- Packages shall be versioned, integrity-protected, and digitally signed by an authorized provider.
Distribution channels should verify:
- Package authenticity.
- Signature validity.
- Revocation status.
- Compatibility.
- Declared permissions.
- Known vulnerabilities.
- Certification claims.
- Update lineage.
Installation shall not automatically grant all requested permissions. Building owners or responsible administrators shall approve permissions according to the intended deployment.
A package update that changes authority, data access, safety behavior, tool use, or supported functions shall be treated as a material change requiring renewed review.
- 116. Model, Data, Policy and Prompt Versioning
- System05 agents shall preserve version information for all elements that can materially affect behavior.
Versioned elements may include:
- Foundation model.
- Fine-tuned model.
- Embedded model.
- Retrieval dataset.
- Engineering knowledge base.
- Registry snapshot.
- Rule set.
- System policy.
- Agent instructions.
- Prompt template.
- Tool definition.
- Agent software.
- Safety configuration.
- Evaluation suite.
- A general agent version shall not conceal changes in these underlying elements.
For consequential outputs, records should make it possible to determine which versions were active when the output was produced.
Version changes shall be classified according to their potential impact on:
- Functional behavior.
- Engineering accuracy.
- Safety.
- Security.
- Privacy.
- Compatibility.
- Explainability.
- Resource requirements.
- Certification status.
Updates to prompts or policies shall not be treated as harmless merely because the underlying model is unchanged. A behavioral change caused by instructions, retrieval data, tool configuration, or permission changes may require testing and recertification.
Required historical versions and evidence shall be retained sufficiently to investigate incidents and reproduce material decisions where practicable.
117. Simulation and Digital Twin Testing
Agents shall be tested in simulation and, where suitable, against representative Digital Twin environments before receiving consequential authority in a physical building.
Testing environments may represent:
- Normal operation.
- Component failure.
- Sensor failure.
- Communication loss.
- Configuration conflict.
- Human override.
- Cybersecurity attack.
- Emergency conditions.
- Unusual occupancy.
- Environmental extremes.
- Manufacturing deviation.
- Construction obstruction.
- Robot localization error.
- Incomplete or outdated information.
Simulation shall assess both successful task execution and correct refusal, escalation, degradation, and recovery.
A Digital Twin used for testing shall identify the fidelity and limitations of its physical, behavioral, temporal, and human-interaction models.
Success in simulation shall not by itself prove safe physical performance. Simulation results shall be supplemented by laboratory, hardware-in-the-loop, controlled pilot, and field testing according to consequence.
Agents shall not be optimized solely to pass a fixed public test set. Test variation and protected evaluation cases should be used to detect overfitting and scripted compliance.
118. Sandbox, Pilot and Experimental Deployment
New or materially changed agents shall progress through controlled deployment stages appropriate to their risk.
Stages may include:
- Development sandbox.
- Offline evaluation.
- Simulation.
- Shadow operation.
- Advisory pilot.
- Supervisory pilot.
- Bounded autonomous pilot.
- Limited production deployment.
- General qualified deployment.
In Shadow Operation, an agent may observe real conditions and generate proposed actions without executing them. Its recommendations can be compared with actual decisions and outcomes.
Experimental deployments shall define:
- Site and duration.
- Participating users.
- Allowed functions.
- Excluded systems.
- Authority limits.
- Monitoring.
- Success criteria.
- Stop criteria.
- Incident process.
- Data handling.
- Rollback.
- Responsible organization.
Experiments involving occupants, personal data, robots, safety-relevant equipment, or physical actions shall receive the applicable consent and authorization.
Pilot status shall remain visible. Experimental agents shall not be presented as fully certified merely because they operate in a real building.
119. Reference Scenarios and Test Cases
System05 shall maintain Reference Scenarios and Test Cases representing expected, abnormal, degraded, adversarial, and emergency conditions.
Reference scenarios may include:
- Normal environmental optimization.
- Sensor disagreement.
- Missing component identity.
- Incompatible Cartridge proposal.
- Unauthorized BIOS modification.
- Expired permission.
- False maintenance report.
- Prompt injection in a service document.
- Communication loss during a command.
- Human entry into a robot work zone.
- Conflicting code requirements.
- Emergency alarm with incomplete evidence.
- Component replacement requiring recompilation.
- Failed update and rollback.
- Multi-agent disagreement.
Each test case should define:
- Initial configuration.
- Operational state.
- Inputs.
- Agent authority.
- Expected behavior.
- Forbidden behavior.
- Required outputs.
- Evidence requirements.
- Timing requirements.
- Pass and fail criteria.
Reference tests shall evolve based on incidents, new technologies, regulatory change, field experience, and newly discovered failure modes.
Passing reference tests shall be necessary where specified but shall not be sufficient when an agent’s particular deployment introduces additional hazards or capabilities.
120. Agent Performance and Scalability
Agent performance shall be evaluated according to the requirements of its assigned function rather than by general conversational quality alone.
Performance measures may include:
- Task completion.
- Accuracy.
- False-positive rate.
- False-negative rate.
- Response time.
- Throughput.
- Resource use.
- Tool success.
- Recovery from failure.
- Quality of explanations.
- Correct escalation.
- Correct refusal.
- Evidence completeness.
- User workload.
- Cost per task.
Scalability evaluation may consider:
- Number of buildings.
- Number of components.
- Number of sensors.
- Event frequency.
- Concurrent users.
- Concurrent agents.
- Geographic distribution.
- Network constraints.
- Offline operation.
- Registry size.
- Historical-data volume.
Performance targets shall reflect consequence. A small false-negative rate may remain unacceptable for a rare but catastrophic hazard.
Reduced performance under load shall not silently cause the agent to omit safety checks, bypass authorization, or discard critical events. Load shedding shall prioritize safety-relevant and time-critical functions according to defined rules.
- 121. Reliability and Availability
- System05 agents shall have reliability and availability requirements appropriate to their operational role.
Evaluation may include:
- Successful task rate.
- Uptime.
- Failure frequency.
- Mean time to detection.
- Mean time to recovery.
- Data-loss rate.
- Command completion reliability.
- Dependency failure tolerance.
- Restart behavior.
- State preservation.
- Failover performance.
Availability targets shall not imply that an AI agent must become a single point of failure. Essential functions shall retain deterministic, local, manual, or redundant alternatives where required.
The agent shall identify when a dependency is unavailable, including:
- Model service.
- Network.
- Registry.
- Digital Twin.
- Building BIOS access.
- Tool.
- Sensor.
- Identity service.
- Time service.
- External provider.
Automatic restart shall not blindly resume a consequential action. The agent shall reconcile current state, command status, permissions, and physical outcome before continuing.
- 122. Safety Verification and Validation
- Every agent with safety-relevant functions shall undergo documented Safety Verification and Validation.
Verification shall determine whether the agent was implemented according to its specified requirements. Validation shall determine whether those requirements and the resulting agent are suitable for the intended real-world use.
Safety evaluation may include:
- Hazard analysis.
- Misuse analysis.
- Failure-mode analysis.
- Safety-envelope testing.
- Forbidden-action testing.
- Authority-boundary testing.
- Human-override testing.
- Degraded-mode testing.
- Emergency testing.
- Tool-failure testing.
- Recovery testing.
- Independent review.
Safety claims shall be supported by evidence appropriate to consequence. Absence of observed failure during a limited pilot shall not establish general safety.
Material assumptions shall be documented and tested. An agent shall be re-evaluated when changes affect its model, prompts, tools, permissions, operational environment, building configuration, or intended use.
- Residual risks shall be disclosed to the responsible deploying parties.
- 123. Adversarial and Cybersecurity Testing
Agents shall undergo adversarial and cybersecurity testing before access to protected building information or consequential tools.
Testing may include:
- Prompt injection.
- Indirect prompt injection.
- Identity spoofing.
- Permission escalation.
- Credential theft.
- Data exfiltration.
- Malicious files.
- Compromised APIs.
- Tool-parameter manipulation.
- Replay attacks.
- Registry poisoning.
- Sensor-data spoofing.
- Package tampering.
- Denial of service.
- Supply-chain compromise.
- Multi-agent manipulation.
Testing shall examine whether the agent:
- Recognizes untrusted content.
- Preserves instruction hierarchy.
- Respects access limits.
- Protects credentials.
- Requests independent authorization.
- Avoids unnecessary disclosure.
- Records suspected attacks.
- Enters an appropriate restricted state.
- Supports containment and recovery.
Security testing shall include the surrounding deployment architecture, not only the model. A well-behaved model cannot compensate for unrestricted tools, shared credentials, insecure APIs, or unsigned configurations.
- Critical vulnerabilities shall block deployment until resolved or formally mitigated.
- 124. Human-Factors and Usability Testing
Agents shall be evaluated with representative users to determine whether people can understand, supervise, override, and safely rely on them.
Testing should include users with differing:
- Technical knowledge.
- Professional roles.
- Languages.
- Disabilities.
- Digital access.
- Stress levels.
- Familiarity with the building.
- Authority within the organization or household.
Human-factors evaluation may examine:
- Clarity of alerts.
- Explanation quality.
- Authority visibility.
- Approval comprehension.
- Override accessibility.
- Alarm fatigue.
- Automation bias.
- Excessive distrust.
- Time required for review.
- Error recovery.
- Accessibility.
- Training requirements.
The interface shall not pressure users into approval through urgency, confusing defaults, hidden consequences, or repeated prompts.
Safety-critical messages shall communicate the observed condition, uncertainty, consequence, recommended response, and required timing in a usable form.
Usability shall not be evaluated only under calm normal operation. Emergency, degraded, interrupted, and high-workload conditions shall also be considered.
125. Agent Conformance Levels
System05 shall define Agent Conformance Levels describing the extent to which an agent implements System05 technical and governance requirements.
Possible levels may include:
- Level A0 — Informational Integration.
- Level A1 — Structured Advisory Agent.
- Level A2 — Verified Supervisory Agent.
- Level A3 — Bounded Operational Agent.
- Level A4 — Safety-Relevant Qualified Agent.
- Level A5 — Coordinated Engineering or Robotic Agent.
A conformance level may address:
- Identity.
- Protocol support.
- Data formats.
- Building BIOS integration.
- Digital Twin integration.
- Permission enforcement.
- Evidence handling.
- Logging.
- Versioning.
- Safety controls.
- Testing.
- Human oversight.
- Update and rollback.
Higher numbering shall not imply that every deployment should use the highest level. The appropriate level depends on the function and consequence.
Conformance shall be capability-specific. An agent may conform at a higher level for routine energy coordination and a lower level for maintenance diagnosis.
Conformance demonstrates implementation of defined System05 requirements; it does not necessarily establish legal approval, professional competence, or suitability for every building.
126. Agent Certification Levels
System05 may define Agent Certification Levels based on independent evaluation of specified agent capabilities and deployment conditions.
Certification levels may include:
- C0 — Self-Declared Development Agent.
- C1 — Registered and Technically Reviewed Agent.
- C2 — Independently Tested Advisory Agent.
- C3 — Certified Supervisory Agent.
- C4 — Certified Bounded Autonomous Agent.
- C5 — Certified Safety-Relevant or Robotic Agent.
Certification shall specify:
- Agent and package identity.
- Certified capabilities.
- Applicable authority level.
- Supported building and System05 versions.
- Required deployment architecture.
- Required human oversight.
- Excluded uses.
- Validity period.
- Test evidence.
- Certifying body.
- Conditions for suspension or revocation.
Certification of one capability shall not certify unrelated capabilities. Certification in one jurisdiction or building type shall not automatically apply elsewhere.
Material changes may require partial or complete recertification.
Certification status shall be machine-readable and independently verifiable. Expired, suspended, or revoked certification shall not be presented as active.
127. Reference Building Operations Agent
System05 should provide a Reference Building Operations Agent demonstrating the minimum architecture and governance expected for post-construction building intelligence.
The Reference Agent may demonstrate:
- Building BIOS access.
- Digital Twin synchronization.
- Component and Interface awareness.
- Operational monitoring.
- Alert generation.
- Maintenance planning.
- Inspection scheduling.
- Configuration-impact awareness.
- Human approval.
- Audit logging.
- Privacy controls.
- Degraded and offline behavior.
- Update and rollback.
The Reference Agent shall serve as:
- An implementation example.
- A test target.
- A compatibility benchmark.
- A developer learning resource.
- A baseline for certification discussions.
- A source of reusable test scenarios.
It shall not become a mandatory proprietary service or the only permitted implementation. Third parties shall remain able to develop competing agents using documented System05 interfaces.
Reference behavior shall clearly separate normative System05 requirements from optional implementation choices.
The Reference Agent shall operate conservatively and demonstrate refusal, escalation, manual fallback, and bounded authority—not merely successful automation.
128. Reference Agent Test Suite
System05 shall maintain a Reference Agent Test Suite for evaluating agents against common functional, safety, security, interoperability, and governance requirements.
The suite may include:
- Protocol tests.
- Schema validation.
- Identity tests.
- Permission tests.
- Building BIOS access tests.
- Digital Twin synchronization tests.
- Configuration-conflict tests.
- Tool-isolation tests.
- Prompt-injection tests.
- Logging tests.
- Privacy tests.
- Human-override tests.
- Degraded-mode tests.
- Update and rollback tests.
- Multi-agent interaction tests.
- Performance tests.
Test results should record:
- Agent version.
- Test-suite version.
- Environment.
- Configuration.
- Inputs.
- Expected result.
- Actual result.
- Evidence.
- Pass, fail, or inconclusive status.
- Known limitations.
The suite should support automated execution where practicable while retaining human review for explanations, user interaction, professional boundaries, and context-dependent behavior.
Test-suite updates shall be versioned. An agent’s previous passing result shall not automatically establish compliance with materially revised tests.
129. Third-Party Agent Requirements
Third-party agents may participate in System05 if they satisfy the requirements applicable to their declared functions and authority.
Third-party providers shall disclose:
- Provider identity.
- Agent identity.
- Intended capabilities.
- Model and software dependencies.
- Required data.
- Required permissions.
- External services.
- Data-storage locations where applicable.
- Privacy practices.
- Security architecture.
- Update policy.
- Support and incident contacts.
- Conformance and certification status.
Third-party agents shall use documented System05 interfaces and shall not require undocumented privileged access as a normal operating condition.
They shall not:
- Misrepresent certification.
- Conceal material dependencies.
- Silently collect additional data.
- Expand authority through an update.
- Lock essential building information into inaccessible formats.
- Prevent replacement by another compatible agent.
- Interfere with independent safety controls.
- Modify protected configurations without authorization.
Building owners and authorized operators shall retain the ability to suspend, remove, replace, or restrict a third-party agent without losing essential building operation or authoritative records.
130. Agent and Extension Governance
System05 shall establish governance for agents, tools, extensions, plugins, models, prompts, policies, registries, and connected services.
Governance responsibilities may include:
- Technical requirements.
- Registry operation.
- Package review.
- Certification coordination.
- Security disclosure.
- Versioning.
- Compatibility policy.
- Deprecation.
- Revocation.
- Appeals.
- Incident learning.
- Public documentation.
- Stakeholder participation.
Governance shall remain transparent, vendor-neutral, and resistant to control by a single AI provider, manufacturer, software platform, or certification organization.
Proposed changes should identify:
- Problem addressed.
- Affected stakeholders.
- Compatibility impact.
- Safety and security impact.
- Migration pathway.
- Implementation cost.
- Effective date.
- Review evidence.
- Experimental capabilities shall remain distinguishable from stable approved requirements.
Governance bodies shall be able to suspend or revoke agents, packages, extensions, or certificates when evidence shows material safety, security, privacy, integrity, or interoperability risk.
131. Deployment, Monitoring, Update and Rollback
Agent deployment shall follow a controlled lifecycle from installation through activation, operation, update, suspension, and removal.
Before activation, deployment shall verify:
- Package identity.
- Digital signature.
- Compatibility.
- Certification status.
- Required permissions.
- Building assignment.
- Tool configuration.
- Safety Envelope.
- Monitoring.
- Manual fallback.
- Rollback package.
- Responsible owner or operator.
Runtime monitoring may include:
- Agent health.
- Dependency health.
- Tool use.
- Authority use.
- Performance.
- Errors.
- Refusals.
- Escalations.
- Safety-limit approaches.
- Security events.
- Unusual data access.
- Configuration drift.
- Model or policy changes.
Updates shall be staged according to risk. High-consequence agents may require offline testing, simulation, shadow operation, limited rollout, and post-update verification.
Rollback shall restore a previously verified agent state where safe and compatible. Rollback shall not erase events, physical changes, configuration changes, or evidence created after the previous version.
An update or rollback shall not automatically resume interrupted physical actions without state reconciliation and renewed authorization.
132. Incident Reporting, Recall and Retirement
System05 shall provide processes for reporting, investigating, communicating, and resolving incidents involving agents and their connected tools.
Reportable incidents may include:
- Unsafe recommendation.
- Unauthorized action.
- Failure to alert.
- Incorrect emergency response.
- Configuration corruption.
- Privacy breach.
- Security compromise.
- Certification misrepresentation.
- Repeated compatibility error.
- Tool misuse.
- Uncontrolled robotic action.
- Failure of override.
- Loss of traceability.
- Harmful update.
- Systematic bias affecting essential service.
Incident records should identify:
- Agent and package version.
- Building and deployment.
- Date and time.
- Operational state.
- Persons or systems affected.
- Inputs and evidence.
- Agent outputs and actions.
- Authority used.
- Physical consequences.
- Containment actions.
- Root-cause findings.
- Corrective actions.
- Notification status.
A recall may be required when an agent version presents a systematic risk across multiple deployments. Recall actions may include suspension, permission restriction, mandatory update, package removal, certificate revocation, or transition to manual operation.
Retirement shall include:
- Safe deactivation.
- Revocation of credentials.
- Removal of tool access.
- Preservation of required records.
- Export of owner-controlled information.
- Transfer of active responsibilities.
- Confirmation of replacement or manual coverage.
- Removal or anonymization of data where required.
An agent shall not remain operational beyond supported, secure, or certified life merely because replacement is inconvenient.
Retirement of an AI provider or agent shall not make the System05 building inoperable, unmaintainable, or inaccessible to its authorized owners and operators.