Suppose you need to run a comparative degradation study across a mixed-OEM solar portfolio. You pull Huawei exports from two sites, Enphase data from another, and Solarman CSVs from two more. Before you can ask a single research question, you're debugging timestamp mismatches, reconciling fault codes, and writing one-off parsers. The research question hasn't changed — but the data plumbing eats the first three days of every study.
ODSE solves the contract problem. Zorora solves the workflow problem. Used together, they give you a repeatable way to run research without rewriting data plumbing for every study.
Operating Model
Think in two layers:
- ODSE: ingestion contract (schema, transform, validation)
- Zorora: deterministic research orchestration (routing, multi-step analysis, synthesis)
OEM data -> ODSE transform -> ODSE validation -> ODSE records -> Zorora workflows -> research outputsPattern 1: Portfolio Baseline Normalization
Use when: You need one baseline dataset across Huawei/Enphase/Solarman before any comparative analysis.
Input: Mixed OEM exports for the same reporting period.
Output: Single ODSE-aligned dataset with consistent timestamps and error taxonomy.
from odse import transform
site_a = transform("huawei.csv", source="huawei")
site_b = transform("enphase.json", source="enphase")
site_c = transform("solarman.csv", source="solarman")
portfolio = site_a + site_b + site_cPattern 2: Validation-Gated Research Ingestion
Use when: Your research quality depends on hard rejection of malformed or ambiguous records.
Input: ODSE candidate records from the transform stage.
Output: Validated corpus + explicit error ledger for auditability.
from odse import validate
result = validate("portfolio_odse.json", level="semantic", capacity_kw=10.0)
if not result.is_valid:
print(result.errors)
raise ValueError("Fix data contract violations before research run")Pattern 3: Completeness and Data Reliability Profiling
Use when: You need to quantify confidence before computing trends, regressions, or forecast backtests.
Input: Validated ODSE records by site and interval.
Output: Missingness map, gap windows, reliability score by site.
This pattern is essential when you're working with South African and frontier-grid conditions where connectivity interruptions can mimic operational events.
Pattern 4: Cross-OEM Fault Taxonomy Studies
Use when: You need to analyze failure behavior across sites with different vendor ecosystems.
Input: ODSE records with normalized error_type and preserved OEM-native codes.
Output: Comparable incident distributions and triage signals across portfolios.
Without ODSE normalization, "top-3 fault classes" is usually meaningless at portfolio level. With it, your fault analytics become comparable and reproducible.
Pattern 5: Benchmarking Against External Research Sets
Use when: You need to join field telemetry with benchmark models (for example ComStock/ResStock-aligned workflows).
Input: ODSE records + building/asset metadata mappings.
Output: Normalized comparative metrics and context-aware performance bands.
The key is that ODSE gives your analysis layer a stable interface regardless of upstream OEM diversity.
Pattern 6: Multi-Source Research Synthesis in Zorora
Use when: You need to combine ODSE data findings with external evidence (standards, policy, market data, technical papers).
Input: ODSE-derived analysis + Zorora deep research workflow prompts.
Output: Structured research brief with citations, assumptions, and decision implications.
In practice, you run ODSE-normalized analysis first, then use Zorora to synthesize your technical findings with external context into an executive-ready output.
Pattern 7: Reproducible Research Packs for Collaboration
Use when: Multiple teams (engineering, operations, finance, policy) need to review the same conclusions with traceability.
Input: ODSE dataset snapshot + validation report + Zorora workflow outputs.
Output: Reproducible research pack that can be rerun and audited.
This pattern is where interoperability turns into institutional memory: same inputs, same pipeline, same conclusions.
Minimal Workflow Blueprint
1) Normalize OEM sources with ODSE transforms
2) Validate with schema + semantic checks
3) Profile completeness and reliability
4) Run question-specific analysis
5) Use Zorora for multi-source synthesis
6) Publish reproducible research packWhere Zorora Fits
Zorora is especially useful once you've stabilized your data contract with ODSE. At that point, workflow routing and synthesis can focus on actual research questions instead of per-vendor parsing issues. That's the difference between ad-hoc analysis and a repeatable research system.
For implementation context, teams can align this with local Zorora workflows in ~/Workbench/zorora and internal platform integrations at code.asoba.co.
Use one OEM feed to establish an ODSE contract, run validation on one historical month, then apply these 7 patterns in sequence.