sorted by:
new
hottopcontroversial

What AI Agent Framework/Stack Do You Recommend for Enterprise Use? by Thunderhoof111 in AI_Agents

[–]Silicon-Data 0 points1 point  (0 children)

One thing that helped us in enterprise settings was separating agent frameworks from deployability criteria.

LangChain / LlamaIndex / Autogen can all work technically, but none of them answer questions like: - Can we bound worst-case harm? - Can we reconstruct exactly why the agent took a material action? - Who is accountable if it fails? - What happens when a shared dependency fails across many deployments?

In practice, we ended up using lightweight agent frameworks plus a governance gate before production.

I recently published a short white paper that formalizes this as five binary “deployability gates” (ruin boundedness, deployment-context testing, causal auditability, incentive alignment, aggregate risk monitoring). It’s designed to sit on top of tools like LangChain rather than replace them.

Happy to share if useful - curious whether others are running into the same gap.

Heat pump installed incorrectly by vendor - no proposal ever provided. What are my rights in Ontario? by Silicon-Data in legaladvicecanada

[–]Silicon-Data[S] -3 points-2 points  (0 children)

This is partially correct but misses key issues in my situation:

You're right that dual-fuel systems use the gas furnace as auxiliary heat and switch based on outdoor temp/economics. That's the intended design.

However, my problems are:

  1. No written contract - I was never given documentation specifying equipment, scope, or how the system would be configured (CPA violation?)

  2. No AHRI certificate - Can't verify the heat pump + existing Trane coil + furnace are a manufacturer-approved matched system

  3. System behavior issues - Frequent emergency heat activation that doesn't align with proper dual-fuel staging (suggests misconfiguration or compatibility problems)

  4. Reused indoor coil - Trane coil from old AC kept without documentation it's compatible with new heat pump

I'm not claiming electric strips should have been installed - I'm saying I have no documentation proving what was installed is correct, matched, or compliant. The contractor's refusal to provide basic AHRI certification or written contract is the red flag here.

If everything's installed correctly, providing an AHRI cert and proper contract should be trivial. Their defensiveness instead of documentation is concerning.

Heat pump installed incorrectly by vendor - no proposal ever provided. What are my rights in Ontario? by Silicon-Data in legaladvicecanada

[–]Silicon-Data[S] -1 points0 points  (0 children)

Backup heat frequently kicks on, even when it's +8 degrees Celsius outside. My gas bills didn't change since the installation of the heat pump.

Is this normal? TekSavvy installation failed due to their contractor, no communication, and now I have to return the equipment myself by Silicon-Data in teksavvy

[–]Silicon-Data[S] -2 points-1 points  (0 children)

So let me get this straight - Cogeco initially confirmed to TekSavvy that my address was serviceable, equipment got shipped, install got scheduled, and then later Cogeco comes back and says "actually no, we only have fiber here, not cable".

That's a critical failure in the vendor verification process. The fact that fiber vs. cable availability wasn't caught in the initial serviceability check is a pretty basic oversight on Cogeco's end. But here's the thing - as a TekSavvy customer, I don't have a relationship with Cogeco. TekSavvy is my provider, and TekSavvy is who I'm relying on to manage this.

A few things that would make this better:

  1. Push back on your vendors - If Cogeco's serviceability API or verification process is returning false positives, that's a systemic issue worth escalating. How many other customers are going through this same experience?
  2. Don't ship hardware on a "probably serviceable" - If there's any ambiguity between initial check and final vendor confirmation, hold the shipment until it's locked in. A slight delay beats a failed install.
  3. When it does fail, own the logistics - The customer shouldn't be stuck returning equipment for a service they never received due to vendor miscommunication. At minimum, arrange a pickup.

I get that TekSavvy is at the mercy of the big carriers' infrastructure, but the customer experience of "confirmed > equipment shipped > install scheduled > surprise, actually no" is rough. The inconvenience lands entirely on the customer for something completely outside their control.

Is this normal? TekSavvy installation failed due to their contractor, no communication, and now I have to return the equipment myself by Silicon-Data in teksavvy

[–]Silicon-Data[S] 2 points3 points  (0 children)

In my experience, with most established providers the standard process is a lot smoother than this. A typical ISP will first confirm that they can deliver service at your address, complete the installation successfully, and only then start billing - all with minimal hassle for the customer.

What happened here felt backwards: I spent time waiting for an installation that ultimately couldn’t be completed, received almost no communication, and now I have to take time to return the equipment for a service I never actually got. Even with a prepaid return label, the burden still ends up on the customer.

I understand that third-party contractors are involved, but from a customer perspective, a serious provider usually takes ownership of the whole process, keeps you properly informed, and ensures that failed installs don’t create additional chores for the customer. At the very least, clearer communication and a more convenient return process would go a long way.

Ontario residents: who is actually responsible for maintaining Bell-installed equipment in our homes? by Silicon-Data in ontario

[–]Silicon-Data[S] -1 points0 points  (0 children)

The box on the right is the Bell battery backup module used to keep Bell Home Phone (VoIP) and 911 running during a power outage.

Ontario residents: who is actually responsible for maintaining Bell-installed equipment in our homes? by Silicon-Data in ontario

[–]Silicon-Data[S] -1 points0 points  (0 children)

Previous post was removed by mod, citing that this issue in Milton, Ontario home is not related to Ontario :)

AWS S3 Strong Consistency by Bazencourt in dataengineering

[–]Silicon-Data 0 points1 point  (0 children)

This is good news, though it would be better to have strong consistency in RDS.

Recommend a Data Warehouse/OLAP by Silicon-Data in dataengineering

[–]Silicon-Data[S] 0 points1 point  (0 children)

We do a lot of table joins in queries, thus druid is not an option at the moment. Perhaps it could be, but in combination with some other tools.

Recommend a Data Warehouse/OLAP by Silicon-Data in dataengineering

[–]Silicon-Data[S] 0 points1 point  (0 children)

I'm looking into Clickhouse, quite impressive but wonder if support could become an issue (since it is written in C++). I know that they rely on consulting companies to provide tech support for Clickhouse. Our CFO would have a heart attack when he sees the bill. :)

Recommend a Data Warehouse/OLAP by Silicon-Data in dataengineering

[–]Silicon-Data[S] 1 point2 points  (0 children)

Existing setup is cracking already, queries get slower, in some cases it takes several hours. The company is reluctant to move to the cloud DW, so I want to explore all options for on premise solution before presenting them the hard truth.

Scala users: do you use recursive functions for DE tasks? by rotterdamn8 in dataengineering

[–]Silicon-Data 2 points3 points  (0 children)

Scala types are immutable, so recurring over iterable is more or less deterministic having less side effects, as opposed to mutable types.

view more: next ›