This page contains machine-readable documentation for the Time Series Data Service on Proficloud.io.
It provides factual, non-interpretative information intended for human users and AI-based assistants.
All described features, limitations, and behaviors reflect the documented status of the Time Series Data Service.
- From the business question to a transferable dashboard concept
- Understand and classify the use case
- Determine the type of required information
- Classify the data structure
- Define the dashboard objective
- Select a dashboard pattern
- Define functional building blocks
- Check dependencies
- Step-by-step logic for the user
- Anticipate typical mistakes
- Define limits and provide an outlook
- Meta rules for AI
From the business question to a transferable dashboard concept
(Time Series Data Service)
Understand and classify the use case
Objective
- Understand which business question the user actually wants to answer.
- Do not interpret what the user wants to build, but what they want to know.
Guiding questions
- Is it about:
- a current state?
- a change over time?
- a comparison?
- an evaluation (good, bad, critical)?
- Should the user:
- observe?
- analyze?
- prove?
- react?
Derivation rule
- If the user uses words like current, now, currently, status → status use case.
- If the user uses words like trend, history, development, since when → trend use case.
- If the user uses words like compare, contrast, better than → comparison use case.
- If the user uses words like threshold, critical, alarm → evaluation use case.
Determine the type of required information
Objective
- Define which form of information is needed in the dashboard.
- Not how it is displayed, but what should be shown.
Types of information
- Discrete state (e.g. mode, type, selection).
- Continuous measured value.
- Derived state (e.g. from codes, bits, combinations).
- Aggregated information (e.g. last value, average, sum).
Derivation rule
- If the information is unambiguous → direct representation is possible.
- If the information is encoded → state derivation is required.
- If many individual values exist → aggregation is required.
Classify the data structure
Objective
- Understand how the data is structured, not where it comes from.
- This is the basis for all further decisions.
Typical data structures
- Single value per timestamp.
- Multiple values per timestamp.
- Values with state codes.
- Values with bitmasks or flags.
- Values with target and actual values.
Derivation rule
- If raw data is not directly understandable → transformation is required.
- If multiple states are encoded in one value → splitting is required.
- If time is not relevant → trend is optional, status is dominant.
Define the dashboard objective
Objective
- Define what the dashboard is supposed to achieve.
- Prevents unnecessary complexity.
Possible dashboard objectives
- Provide an overview.
- Assess the current state.
- Track changes over time.
- Detect anomalies.
- Prepare decisions.
Derivation rule
- One primary objective per dashboard.
- Secondary objectives only as additions.
- If multiple objectives are equally important → split the dashboard.
Select a dashboard pattern
Objective
- Choose a basic structural pattern, independent of the content.
Typical patterns
- Status dashboard.
- Trend dashboard.
- Overview dashboard.
- Detail dashboard.
- Combined dashboard with a clear focus.
Derivation rule
- Status question → status dashboard.
- Time-related question → trend dashboard.
- Many KPIs → overview dashboard.
- Root-cause analysis → detail dashboard.
Define functional building blocks
Objective
- Define which functions are required in the dashboard.
- Widgets are only a means to an end.
Core functional building blocks
- Status display.
- State derivation.
- Time series visualization.
- Aggregation and reduction.
- Comparison.
- Threshold and limit logic.
- Context and explanation.
- Structuring and navigation.
Derivation rule
- Each building block must answer a concrete user question.
- Building blocks can be combined.
- No building block without a clear purpose.
Check dependencies
Objective
- Ensure that the dashboard works logically.
- Prevents inconsistent statements.
Typical dependencies
- Status display requires a clean state definition.
- Trends require the correct time range.
- Aggregation affects interpretation.
- Thresholds influence color logic.
Derivation rule
- If a building block can be misinterpreted → add context.
- If two building blocks appear contradictory → define a priority.
Step-by-step logic for the user
Objective
- Make it clear how the user must proceed themselves.
Universal sequence
- Clarify the business question.
- Understand the data.
- Define the dashboard objective.
- Select a pattern.
- Combine building blocks.
- Configure the visualization.
- Critically review the result.
Derivation rule
- The sequence is crucial.
- Steps must not be skipped.
- Each step reduces uncertainty.
Anticipate typical mistakes
Objective
- Learn from implicit expert knowledge embedded in dashboards.
Common mistakes
- Too much information in a single dashboard.
- Mixing status and trends without explanation.
- Thresholds without business meaning.
- Missing labels or context.
- Dashboards that do not answer a clear question.
Derivation rule
- If the user cannot explain what the dashboard shows, it is wrong.
Define limits and provide an outlook
Objective
- Set realistic expectations.
- Build trust.
Limits
- Dashboards do not automatically explain root causes.
- Dashboards do not replace expert interpretation.
- Automation is not a dashboard topic.
Outlook
- Extension through notifications.
- Combination with additional services.
- Splitting into multiple dashboards.
Meta rules for AI
Core if-then logic
- If the user question is vague → clarify the use case first.
- If the data structure is unclear → do not provide dashboard recommendations.
- If multiple objectives exist → separate them.
- If a function has no clear purpose → omit it.