FAQs: DataSide®  Platform with inbuilt DaysaTM AI (LLM) Interface

The short Answer

Claude is an AI reasoning engine and assistant.

DataSide is a managed service that brings business data together, applies agreed rules and permissions, and makes that data usable, and queryable in plian-English through Daysa, its AI interface.

This is not a choice between two similar chatbots.

It is a choice about who will integrate, govern and operate the data behind the answers your business relies on. In some solutions, Claude can sit inside the DataSide architecture as the reasoning engine.

Best uses at a glance

Understanding the difference

Is DataSide another AI assistant like Claude?

No. Claude provides language and reasoning capability. DataSide provides the wider operating environment around business data: connecting sources, aligning records, applying agreed definitions and permissions, and keeping the service running. Daysa is the DataSide interface through which users ask business questions.

What is Claude best suited to?

Claude is well suited to broad knowledge work such as drafting, summarising, analysing documents, coding and helping employees think through problems. It also gives internal technology teams flexible model and API access when they want to build and operate their own applications.

What is DataSide best suited to?

DataSide is intended for questions that depend on consistent information from multiple business systems - for example finance, customer, project, delivery or workforce platforms. It is most relevant when the organisation needs repeatable answers, agreed calculations, controlled access and a clear owner for the service.

Does DataSide replace Claude?

Not necessarily. The two can play different roles. Claude can provide the reasoning capability, while DataSide provides the connected data foundation, business rules, access controls and managed operation. The value of DataSide is not simply access to an AI model; it is the complete business-data outcome around that model.

Common buying questions

Why not just buy Claude Enterprise?

Claude Enterprise may be the simpler choice for broad employee AI assistance. However, buying an enterprise AI assistant does not by itself reconcile customers, projects, employees, revenue or history across your operating systems. If you need governed operational answers, that integration and definition work still has to be designed, tested, maintained and supported.

Why pay for DataSide if it can use Claude?

Because DataSide is purchased for the work around the model: bringing data together, improving consistency, applying business definitions and permissions, providing traceability, and taking responsibility for ongoing operation. A simple analogy is that an engine is important, but it is not the whole vehicle or the service that keeps it on the road.

Can't our technology team build this themselves?

They may be able to. The business decision is whether building and running the complete data-and-AI service is the best use of their time. A production solution still needs people to manage connections, data changes, permissions, testing, monitoring, costs, incidents and user support over time.

Claude can connect to business content. Isn't that enough?

A connection gives the AI access to information; it does not automatically make the information consistent. Different systems may use different names, dates, statuses or calculations for the same customer, employee, project or metric. DataSide is designed to address that reconciliation and definition layer before the information is used for business decisions.

What about security and privacy?

Claude offers enterprise controls, and it should not be positioned as lacking enterprise security. The additional question for any cross-system solution is how controls work across the entire data flow: source systems, stored data, permissions, AI processing, logs, support roles and incident response. DataSide is designed to operate in a dedicated, governed AWS environment, with the final architecture and responsibilities agreed for each customer.

What the business receives

What does DataSide do before an answer reaches the user?

In plain terms, DataSide brings selected data into a controlled environment, standardises it, matches related records across systems, applies agreed business definitions and access permissions, and prepares it for use. Daysa then provides a focused way for users to ask questions of that governed information.

What is Daysa?

Daysa is DataSide's built-in AI interface. It is configured to work with the organisation's connected data and agreed business context. Its purpose is to make business questions easier to ask and the resulting answers more relevant, controlled and traceable than a general-purpose chat experience.

What kinds of outcomes should we expect?

The starting point should be a specific business question, not a promise that AI will solve everything. Useful outcomes may include earlier visibility of risk, more consistent reporting, less manual reconciliation, and identification of process improvements or automation opportunities. The exact outcome depends on the connected data, agreed definitions and use case.

Making the right choice

When is direct Claude the better choice?

Direct Claude is likely to be better when the main need is general writing, coding, document analysis or employee assistance; when curated data and a capable build-and-run team already exist; or when model experimentation matters more than a managed business outcome. DataSide should not be forced into a use case that does not need a governed cross-system data service.

How should we evaluate the options?

Start with one valuable business question that requires information from more than one system. Identify the data it needs, the calculation or definition that must be trusted, who can see the answer, who will maintain the solution, and when it needs to be live. Then compare the options on the complete outcome - not only the AI model.

A USEFUL FIRST QUESTION What cross-system business answer do we need, what data and definition support it, and who will own it in production?

What to ask for in a DataSide demonstration

A real business question: Use a question that requires data from more than one source system.

A clear calculation: Show the agreed meaning of the metric and how it is applied.

Traceability: Show where the answer came from and how authorised users can verify it.

Operating responsibility: Explain who manages source changes, monitoring, incidents and support.

A realistic path to value: Set out what must be connected, agreed and tested before the use case is live.

Where is DataSide hosted?

The supplied material describes DataSide as AWS-native and typically deployed in a dedicated or isolated AWS environment. The exact AWS account, region, tenancy pattern and commercial ownership must be defined for each customer.

Does each customer receive a dedicated AWS account?

A separate AWS account per customer is the clearest isolation model and is described in parts of the supplied material; other passages allow logical separation. The final model must be confirmed in the solution architecture and contract.

Who owns the AWS account and cloud subscriptions?

The customer should own the production cloud account and grant Sida4 controlled administrative access, or the contract should clearly identify Sida4 as the service provider and define data ownership, access, exit and cost transparency. The selected model must be stated in the order form and architecture.

How are environments separated?

A deployment would provide separate development, test or staging, and production environments, with controlled promotion, separate credentials and production change approval. Lower environments should use masked or synthetic data unless production data is specifically authorised.

How is infrastructure deployed and changed?

The supplied notes state that infrastructure is defined and provisioned using Terraform. This supports repeatable deployments, reviewable changes and promotion between environments. The exact source-control, approval and deployment pipeline is customer-specific.

How is network isolation implemented?

The supplied notes describe isolated VPCs and private subnets. A best-practice design would use private connectivity where practical, tightly controlled ingress and egress, security groups, endpoint policies, network logging and no public administrative access.

Can DataSide be deployed outside AWS or on premises?

The supplied materials establish AWS as the native platform. Multi-cloud or on-premises deployment is not confirmed and should be treated as a separately assessed architecture rather than a standard option.

How is data residency selected?

The deployment region should be agreed with the customer and pinned in the architecture and contract. Data, backups, logs, support access and third-party services should be reviewed together because residency can be affected by more than the primary database.

What is the normal implementation sequence?

• Confirm use cases, systems, data owners and success measures.

• Complete architecture, security, privacy and commercial discovery.

• Provision environments and access.

• Configure connectors and initial ingestion.

• Profile, map, validate and reconcile data.

• Configure analytics, workflows or Daysa use cases.

• Conduct functional, security, performance and user acceptance testing.

• Approve production release, operating procedures and support handover.

Is a 90-day outcome guaranteed?

No. The notes describe a design goal of producing measurable value within a 90-day cycle. Actual timing depends on source-system access, data condition, connector availability, security approvals, customer participation and scope. Any committed date belongs in the statement of work.

What types of sources can DataSide connect to?

The platform is designed to connect SaaS applications, relational databases, files, object stores, APIs and event feeds. Supplied examples include HubSpot, Xero, JobAdder, Polaris / Replicon, Salesforce, MySQL, PostgreSQL, Oracle and Amazon S3.

Are all connectors pre-built?

No. Some connectors may be standard, some may require configuration, and others may require custom engineering. Connector availability, supported objects, API limits, historical extraction and maintenance responsibility must be confirmed during discovery.

How are credentials managed?

Credentials should be held in an approved secrets-management service, encrypted, rotated, restricted by least privilege and excluded from code and logs. Customer and Sida4 responsibilities for issuing and rotating credentials should be documented.

How frequently is source data refreshed?

Refresh frequency depends on the source, API constraints, connector pattern and selected service tier. Event-capable sources may be near real time; other sources may run on a schedule. The agreed frequency should be listed per connector in the data interface specification.

Does “real time” mean instantaneous?

No. “Real time” should be used carefully. End-to-end latency includes source emission, connector polling, streaming, processing and destination availability. Each critical flow should have a measurable latency objective rather than relying on the phrase alone.

How are schema changes handled?

The platform approach supports schema validation and infrastructure-as-code. A best-practice operating model would detect incompatible source changes, quarantine affected records, alert support, maintain versioned schemas and require controlled remediation.

What happens when records fail validation?

The supplied architecture refers to retry logic and dead-letter queues. A best-practice implementation would preserve the failed record and reason, retry transient failures, alert on thresholds and provide a controlled replay process after correction.

How are entities matched across systems?

DataSide can maintain cross-reference entities and links that associate records from separate systems with a canonical entity. Matching may use stable identifiers, deterministic rules and reviewed mapping. AI-inferred matches should not be treated as fact without confidence controls and human review.

Who is responsible for source data quality?

The customer remains accountable for the meaning and quality of data in its source systems. DataSide can detect, report, transform or quarantine issues within agreed rules; it cannot make unknown or incorrect source information true.

Can DataSide load historical data?

Historical backfill is technically possible where the source exposes the required history. Volume, retention, API throttling, data quality and reconciliation effort should be scoped separately from steady-state ingestion.

Where is processed data stored?

Storage depends on the selected blueprint. The supplied notes describe MongoDB for operational data, Amazon S3 for raw and processed objects, Snowflake for analytics and Amazon RDS for structured metadata as supported patterns.

Does DataSide require Snowflake?

No. Snowflake is an optional analytical destination or component. The solution should select storage based on workload, performance, governance, customer standards and cost.

What role does MongoDB play?

The supplied material describes MongoDB as an operational store and as the dedicated data source interrogated by Daysa in the current pattern. Database topology and tenancy must be confirmed for each customer.

How is data lineage maintained?

DataSide records source, ingestion time, transformations, schema version, destination and job or event identifiers so important figures can be traced back to source evidence. Exact lineage tooling and coverage are confirmed for each implementation.

How is data reconciled?

Critical financial and operational feeds should have control totals, record counts, amount totals, completeness checks and exception reporting matched to the source system. Reconciliation rules and tolerances should be agreed per data product.

Can DataSide feed existing BI tools?

Yes. Power BI is explicitly referenced, and the platform pattern can deliver governed data to other supported consumers through agreed interfaces. Tool-specific support and licensing must be confirmed.

Who owns customer data and derived data products?

The customer retains ownership of its source data and customer-specific derived datasets. Sida4 retains ownership of the DataSide platform, reusable code, templates and general know-how. The contract defines the rights required to operate the service, use de-identified telemetry and deliver customer-specific outputs.

How is DataSide monitored?

The supplied material describes OpenTelemetry and Amazon CloudWatch for metrics, traces, logs, alerting and FinOps insights, together with centralised operational monitoring.

Is monitoring provided 24/7?

DataSide provides automated monitoring 24 hours a day, seven days a week. This is distinct from staffed 24/7 service-desk coverage, which depends on the contracted support tier.

What uptime does DataSide guarantee?

Availability targets and service credits are not established in the supplied material. The contract should define the measured service boundary, maintenance exclusions, calculation method, target percentage and remedy.

What are the recovery time and recovery point objectives?

RTO and RPO must be set by workload and service tier after business impact analysis. Critical ingestion, storage, analytics and Daysa components may have different recovery objectives.

How are backups managed?

A best-practice design would use encrypted automated backups, separate access controls, lifecycle policies, restore testing and protection from accidental or malicious deletion. Coverage and retention should be listed for each stateful component.

How often are restores tested?

Critical services have documented restore tests at least annually, with more frequent testing for higher criticality. Test evidence, exceptions and remediation is retained.

Does DataSide provide multi-region disaster recovery?

Multi-region recovery is not established as standard. It should be offered only where business impact and data-residency requirements justify the complexity and cost, and must be explicitly designed and priced.

How is planned maintenance handled?

Customers should receive reasonable advance notice for maintenance that may affect service, except emergency changes. Maintenance windows, excluded downtime and communication channels should be stated in the service schedule.

What does “fully managed” include?

The supplied material describes control-plane operation, monitoring, security patching and pipeline maintenance. The signed scope should define precisely which connectors, environments, data products and incidents are covered.

What should standard support include?

·    Incident intake, triage and restoration for supported production components.

·    Monitoring and alert response.

·    Routine platform maintenance and supported-version patching.

·    Connector and pipeline operational support within the agreed catalogue.

·    Service reporting and a documented escalation path.

·    A defined allowance or process for minor service requests.

What is normally outside standard support?

·    New connectors, major enhancements or new data products.

·    Changes caused by undocumented source-system changes or unsupported APIs.

·    Data cleansing or remediation in source applications.

·    Customer training beyond the contracted allowance.

·    Third-party licence fees and vendor professional services unless expressly included.

·    After-hours project work or onsite attendance unless included in the service tier.

What support hours apply?

The base tier will provide business-hours service desk coverage in the agreed Australian time zone, with automated monitoring at all times and a separately priced 24/7 response option for priority-one incidents.

How are incidents prioritised?

·    Priority 1: production service unavailable or critical data flow materially stopped, with no reasonable workaround.

·    Priority 2: material degradation or major function unavailable, with significant business impact.

·    Priority 3: limited impact, non-critical defect or workable degradation.

·    Priority 4: information request, minor issue or planned enhancement.

What response and restoration targets apply?

Targets are defined by priority and support tier. Acknowledgement is not the same as restoration or resolution. Service clocks, customer dependencies, third-party delays and exclusions should be explicit.

How do customers request support?

Customers should use a nominated service portal or support email that creates a tracked ticket. Priority-one incidents should also have a verified telephone or paging path. Authorised contacts and escalation contacts should be maintained.

Does support include data engineering?

Routine correction of a supported pipeline defect may be included. New transformations, changed business logic, new reports, backfills, complex mapping and custom connector work should normally be treated as a change request or professional service.

Who supports third-party products?

Sida4 should coordinate incidents across components it manages, while the underlying vendor retains responsibility for its service. Licence ownership, vendor support entitlement and escalation authority must be recorded.

What service reporting is provided?

A monthly report should cover availability, incidents, SLA performance, pipeline health, data freshness, changes, security events, capacity and consumption. The reporting cadence and measures require confirmation.

How are changes classified?

Changes should be classified as standard, normal or emergency. Standard changes are pre-authorised and repeatable; normal changes require assessment and approval; emergency changes restore service or address urgent risk and receive retrospective review.

Who approves production changes?

Sida4 should approve platform changes within its managed responsibility, while customer approval should be required for changes that materially affect data, interfaces, cost, security, business logic or user outcomes. The RACI should be agreed during onboarding.

How are releases tested?

A best-practice release should pass automated tests, security checks, data reconciliation and environment-specific validation before controlled production promotion. High-impact changes should include rollback criteria and customer acceptance.

How are source-system changes managed?

The customer should notify Sida4 before upgrades, API changes, credential changes or data-model changes that may affect an interface. Sida4 should monitor published vendor changes for supported standard connectors where practical.

How are enhancements requested and priced?

Enhancements should enter a documented change process with scope, assumptions, architecture, security impact, acceptance criteria, price and delivery approach. No enhancement should silently become part of incident support.

What does the customer need to provide?

·    An executive sponsor, product owner and technical contacts.

·    Authorised access to source systems, vendors and test environments.

·    Data owners who can define meaning, quality and reconciliation rules.

·    Security, privacy, legal and procurement participation.

·    Timely decisions, testing and acceptance.

·    Licences and third-party entitlements not included in the DataSide agreement.

What discovery is required?

Discovery should document use cases, source systems, data classification, volumes, latency, history, interfaces, user roles, non-functional requirements, success measures, constraints, dependencies and exit needs.

What implementation artefacts should be produced?

·    Solution architecture and data-flow diagram.

·    Connector and interface catalogue.

·    Data mapping, definitions and reconciliation rules.

·    Security and privacy assessment.

·    Environment and access model.

·    Test and acceptance plan.

·    Runbook, support model and escalation matrix.

·    Commercial schedule and consumption assumptions.

How is acceptance determined?

Acceptance criteria should be objective and agreed before build. They should cover data completeness and accuracy, latency, security, performance, usability, operational readiness and defined business outcomes.

What training is provided?

Training should cover platform consumers, Daysa users, service administrators and support contacts as applicable. The number of sessions, materials, recording rights and ongoing onboarding require confirmation.

What can delay implementation?

·    Slow access or security approval.

·    Poor or undocumented source data.

·    Unavailable or rate-limited APIs.

·    Unclear ownership of business definitions.

·    Late scope changes.

·    Third-party procurement or licensing.

·    Insufficient customer testing capacity.

·    Regulatory or privacy review.

How is DataSide priced?

After initial setup and implementation costs, the DataSide Integration Platform with Daysa AI (LLM) Interface operates on monthly subscription fees and AWS consumption model.

Pending the number of DataSide Connectors required, see below.

A commercial example of the first two years suitable to a wide range of SMBs / SMEs:

Year 1 subscription, with once-off setup fee and up to 3 connectors: $27,500

Year 2 subscription, with up to 3 connectors: $24,000

• Once-off setup and implementation fee $3,50O 
• DataSide Platform with Daysa AI (LLM) Interface, subscription $2,000 per month
• Monthly subscription includes up to three (<3) connectors from the existing DataSide Connectors Library
• Additional Connectors from the Library (existing), $400 per month, per connector
• *If a connector does not already exist in the DataSide Connector Library, then a once-off build fee of $1,500 per connector applies
• Includes 100 GB of DataSide consumption per month
• Consumption above the included allowance is charged using DataSide Compute Units (DCUs), with 1 DCU = $1

DataSide Connectors Library

We are always adding new Connectors to our Library. If we do not have an existing connector your need, a once-off build cost could apply as point 5 above. *If we deem the requested new connector to be of wide enough value to current and/or future DataSide customers, we may reduce or remove the fee on a case by case basis.

*Customisations or bespoke commercial needs are all price on application.

What does the implementation fee cover?

It covers the defined discovery, deployment, configuration, agreed initial connectors, mapping, testing, production release and handover. Anything outside the statement of work should require a change request.

What does the recurring managed service fee cover?

It covers platform access and operation, monitoring, routine maintenance, patching and the contracted support level for the listed environments and components. Cloud and third-party costs may be included, passed through or customer-owned, so the order form must say which.

Are connectors charged separately?

The commercial schedule should identify whether each connector has a one-off implementation charge, recurring maintenance charge, usage charge, or a combination.

What usage is metered?

Potential meters include data processed or moved, storage, compute, streaming capacity, API calls, model tokens, managed database consumption and egress. Only meters expressly listed in the commercial schedule should be billable.

Are there baseline allowances and overages?

The baseline allowances and overages in 100 GB blocks. The included allowance, block calculation, rounding, rate and notification thresholds must be confirmed in the price schedule.

Are prices in AUD or USD?

Invoices are calculated in USD and converted to AUD, but this is not confirmed by the attached notes. The contract should state invoice currency, tax treatment and whether vendor consumption is converted.

When are invoices issued and payable?

The invoice implementation milestones as agreed, recurring fees monthly in advance, and measured consumption monthly in arrears, with Australian GST shown separately and payment due within the contracted term.

What information should appear on the invoice or usage statement?

·    Customer, service period, purchase order and contract reference.

·    Fixed service and connector charges.

·    Included allowances, actual usage, overage calculation and unit rates.

·    Cloud or third-party pass-through charges.

·    Currency conversion source and rate where applicable.

·    GST, credits, adjustments and total payable.

How can a customer challenge a charge?

The customer should notify Sida4 within a defined dispute period, identify the item and basis, and pay undisputed amounts. Sida4 should provide meter evidence and correct verified errors through a credit or revised invoice.

Are consumption alerts available?

Customers can receive configurable warnings before material allowance or budget thresholds are exceeded, together with access to a usage view or report. Availability and alert frequency require confirmation.

How can customers control cost?

·    Set budgets and alerts.

·    Choose refresh rates suited to business need.

·    Apply storage retention and lifecycle rules.

·    Avoid unnecessary duplicate movement or reprocessing.

·    Use smaller or cheaper compute and model options where adequate.

·    Review inactive connectors and low-value data products.

·    Conduct monthly FinOps review.

Which documents define the service?

The proposal, order form, statement of work, master services agreement, service schedule, data-processing terms, security schedule and approved change orders collectively define the service. Signed documents take precedence over this FAQ.

Who owns DataSide intellectual property?

Sida4 / 4impact retains ownership of the DataSide platform, blueprints, reusable software and general methods. Customer-specific rights, configurations and deliverables are defined in the contract.

Can customers export their data?

Customers can export their source data and customer-specific derived data in documented, commonly usable formats, subject to security controls and any agreed extraction charges. Formats, timing and volume limits are confirmed in the service agreement.

What happens at termination?

An exit includes final data export, revocation of access, an agreed transition period, deletion after the retention window, deletion confirmation, and agreed treatment of backups, logs, legal holds and outstanding charges.

How long is data retained after termination?

The period is not established. The contract should set a short retrieval window followed by secure deletion, subject to legal holds, backup expiry and statutory records. Customers should not rely on indefinite retrieval after service end.

Is transition assistance available?

Reasonable transition support should be available at agreed professional-services rates, with scope covering data export, documentation, knowledge transfer and coordination with the replacement provider.

Can Sida4 use aggregated telemetry?

Use is limited to service operation, security, capacity, billing and product improvement, with customer content excluded or de-identified where appropriate. The contract and privacy terms must define permitted uses.

What should a buyer validate before purchase?

·    The exact business outcome and measurable baseline.

·    Connector coverage and source-system constraints.

·    Architecture, tenancy, region and account ownership.

·    Security assurance, privacy roles and subprocessors.

·    Data quality and reconciliation approach.

·    Support hours, SLAs, recovery and escalation.

·    Data portability, termination and deletion.

What proof should be requested in a pilot?

A pilot should demonstrate representative source access, mapping, data reconciliation, latency, security controls, traceable outputs, operational support and a credible cost model. A polished Daysa answer without source evidence is not sufficient proof of the platform.

What are the principal implementation risks?

·    Source access and API constraints.

·    Inconsistent definitions and weak master data.

·    Incorrect entity mapping.

·    Security or data-residency gaps.

·    Uncontrolled consumption cost.

·    Dependence on third-party vendors.

·    Insufficient operational ownership.

·    Unclear contractual boundaries.

What is the right way to start?

Start with one or two valuable cross-system outcomes whose source evidence, owners and success measures are clear. Prove ingestion, reconciliation, operating support and adoption before expanding the platform footprint.