inspectorplatform

Operating System for Municipalities and their Taxpayers to upload photographs to a portal app, that analyzes the image metadata and the image for local building codes and verifies date/time/location of photo for keeping buildings up to code or use for other readings/inputs.

Accessibility Score Governance Spec (InspectorOS v1)

1. Purpose

This specification defines the governance requirements for InspectorOS Accessibility Score generation and use. The Accessibility Score is a decision-support metric and must not be used as the sole basis for permit denial, occupancy action, or enforcement.

2. Scope

This spec applies to:

• Accessibility score computation (accessibility_score, 0-100)
• Score components and weighting profiles
• Evidence and explainability requirements
• Human review gating and overrides
• Fairness, drift, and quality monitoring
• Public visibility controls
• Appeals and correction workflow

This spec does not replace local legal requirements; municipalities remain the authority.

3. Regulatory and Standards Alignment

The scoring framework must map findings to jurisdictional rules including:

• ADA 2010 Standards (or adopted equivalent)
• IBC/IFC accessibility-relevant sections where locally adopted
• Local municipal accessibility amendments

Each score component must reference at least one citation in active CodePack metadata.

4. Score Definition

4.1 Output Contract

ScoreCard.accessibility_score is an integer from 0 to 100 with:

• confidence (0.0-1.0)
• weighted_components
• explainability.evidence_refs
• explainability.code_citations

4.2 Component Model

Accessibility score is derived from:

• Barrier findings by severity (high, medium, low)
• Positive accessibility features present
• Jurisdiction-selected weighting profile
• Mandatory review conditions

Baseline policy:

• Start from 100
• Subtract severity-weighted barrier penalties
• Add limited positive-feature bonus
• Clamp final score to [0, 100]

4.3 Severity Policy

• high: direct route/access impairment or critical accessibility hazard
• medium: substantial accessibility limitation with workaround possible
• low: minor or partial non-conformance

Severity labels must be deterministic and explainable in finding metadata.

5. Human Review and Decision Controls

5.1 Required Human Review Triggers

Human review is mandatory when any condition is true:

• Any high severity accessibility finding
• Any finding confidence below jurisdiction threshold (default 0.72)
• Evidence integrity status not verified
• Rule conflict or unresolved cannot_determine state

5.2 Prohibited Automated Actions

The system must not:

• Automatically deny compliance solely from score value
• Automatically publish enforcement-ready action without human approval

5.3 Override Rules

When reviewers override model findings or score interpretation, the system must capture:

• Reviewer identity
• Rationale text
• Timestamp
• Affected finding/score fields
• Linked audit reference

6. Explainability and Evidence Traceability

Each accessibility-relevant finding must include:

• rule_id
• code_citation
• confidence
• evidence_refs (1+ assets)
• Natural-language finding explanation

Each scorecard must include:

• Component counts used in score computation
• Applied profile name and version
• Evidence and citation references used for score impact

7. Data Quality and Integrity Requirements

7.1 Evidence Minimums

Accessibility scoring should require:

• Capture timestamp
• Geolocation metadata (unless explicitly exempted)
• Device identifier
• Hash-based integrity record

7.2 Integrity Flags

Any of the following sets chain_status=needs_review:

• Missing or invalid GPS
• Invalid capture timestamp
• Metadata tamper mismatch (hash mismatch)

Scores may still be computed for triage, but must be marked non-final pending review.

8. Fairness, Drift, and Performance Governance

8.1 Required Evaluation Slices

Evaluate score performance at minimum by:

• Building type (residential, commercial, civic, mixed-use)
• Building vintage/age ranges
• Jurisdiction and neighborhood cohort
• Capture device class (high-end, low-end, mixed)
• Environmental conditions (lighting/weather where available)

8.2 Fairness and Stability Checks

Run recurring checks for:

• False positive/negative disparity between cohorts
• Confidence calibration drift
• Sudden score distribution shifts by jurisdiction
• Reviewer disagreement rates by cohort

8.3 Release Gates

Do not promote new scoring model/profile versions unless:

• Validation metrics meet jurisdiction baseline thresholds
• Fairness checks are within defined deltas
• Rollback artifact is available
• Governance review is approved

9. Versioning and Change Control

Each score and finding must be traceable to:

• Model version
• Rule pack version
• Scoring profile version
• Effective dates

Change types requiring formal approval:

• Weight changes
• New/removed mandatory conditions
• Confidence threshold changes
• Rule-to-severity mapping changes

10. Public Visibility Policy (Opt-In)

Accessibility scores may be published only if:

• Property is explicitly opt-in or agency-authorized
• Most recent relevant analysis is human-approved
• Record includes “last updated” date
• Public disclaimer states score is decision support, not a legal determination

11. Appeals and Corrections

The system must support a documented appeals flow:

• Owner/agent submits dispute with evidence
• Case assigned to reviewer
• Re-analysis or manual correction performed
• Updated score generated with version linkage
• Previous score retained for history/audit

Appeal SLA and notification policy are jurisdiction-configurable.

12. Accessibility of InspectorOS Interfaces

InspectorOS web/mobile interfaces must target WCAG 2.2 AA:

• Screen-reader compatibility
• Keyboard navigation
• Sufficient contrast
• Captions/alt text support for media evidence workflows where applicable
• Plain-language score summaries

13. Security and Privacy

Required controls:

• Role-based access for evidence and score records
• Tenant isolation by organization/jurisdiction
• Audit logging for read/write/decision actions
• Data retention and deletion policy by jurisdiction
• PII minimization in exported/public datasets

14. Acceptance Criteria for Governance Compliance

A jurisdiction deployment is governance-compliant only when:

• Explainability fields are present in 100% of scorecards
• Human review triggers are enforced without bypass
• Version metadata is present in all scored records
• Appeals workflow is enabled and auditable
• Public map publication policy is enforced

15. Recommended Defaults (v1)

• Confidence review threshold: 0.72
• Publish policy: opt-in and human-approved only
• Model authority: decision support only
• Mandatory audit retention: minimum 24 months (unless stricter local policy)