

ETF Mon 100 is on sale zone as per my model
I have using OU strategy to identify signal to but sale international etf based on premium


I have using OU strategy to identify signal to but sale international etf based on premium
what do you think about this strategy on premium?
I build the new capability in Mosaic called co relation. it first try to find annomaly based on volatility and volume then it try to find co relation? any government, stock action? news?
What cause the price to move.
Here is the whole design
https://github.com/Mosaic-agent/Mosaic-fund-agent/blob/main/docs/anomaly-detection.md
I am using following strategy to identify anomaly in Commodity PeltChangePointStrategy GarchResidualStrategy RobustZScoreStrategy
While it helps in reducing the noise one of the challenge I am facing is in correlating the anamolies to certain event example News ($ index)
If I am using Local model it fills up context which result in bad quality result, if I am using model Like Cloude OPUS, result is great but cost is even higher.
Is there a way to make co relation efficient with local model?
I am exprimenting with 4 step anomaly detection on stock pricing over the period through following steps.
Step 1 — Robust Z-Score (MAD)
Step 2 — GARCH(1,1) Standardised Residual
Step 3 — Isolation Forest Confidence Multiplier
Step 4 — PELT Change-Point Detection (regime-shift confirmation)
After identifying an anomaly, I attempt to determine the underlying cause by correlating it with relevant events and market factors, such as:
Could some one review the model and help in improving it?
After lots of trial and error I finally managed to integrate shoonya api, if some one what to try it out here is the reference.
https://github.com/Mosaic-agent/Mosaic-fund-agent/blob/4cd9df49fd9723daeb2eef6df5629b2a376e0c2f/src/scripts/portfolio/shoonya_login.py
and for live tick here is an example
https://github.com/Mosaic-agent/Mosaic-fund-agent/blob/4cd9df49fd9723daeb2eef6df5629b2a376e0c2f/src/tools/shoonya_tools.py#L90
Purchased a Panasonic AC and within less than a year it has required repeated gas filling/top-ups.
Service history:
Now the issue has reoccurred again and I am being asked to pay as my waraanty expired 3 week back.
One technician previously stated there was no leakage after nitrogen testing, while another technician is now claiming installation issues.
I have asked Panasonic for:
At this stage I am evaluating legal escalation through the consumer forum. Posting here to understand whether others have faced similar recurring issues with Panasonic AC service.
Panasonic is asking my to pay 6k to reinstall copper pipe and refill gas.
Location Pune, Maharashtra
I have dropped this email to Panasonic leadership
Dear Mr. Kamoda and Mr. Chiba,
I am writing to escalate a customer service matter directly to your attention. Prior correspondence with service.head@in.panasonic.com and pi.grievanceofficer@in.panasonic.com over the last week has not produced a substantive response. The case is significant because Panasonic has, this same month, on this same unit, already accepted the underlying principle I am asking the company to apply consistently.
The Product
Service History (13 months, 5 interventions)
The Precedent Panasonic Has Already Set on This Unit
Following my email of 10 May 2026, Panasonic accepted that the relay failure was a direct consequence of improper servicing by your authorised technician, not normal wear. The relay was replaced at no cost, despite the standard warranty having lapsed on 04 April 2026.
This was the right decision, and I appreciate it. It also establishes, in your own service record, the principle that:
When damage on this unit is traceable to negligent work by Panasonic's authorised network, Panasonic accepts financial responsibility, independent of warranty expiry.
I am asking the company to apply that same principle, consistently, to the second defect identified on the same service visit.
The Second Defect: Installation, Not Wear
Reliable Care Solution, the Panasonic authorised agency now handling the case, has independently diagnosed that the copper pipe installed in April 2025 is of incorrect diameter and contains a bend that obstructs refrigerant flow. Their revised estimate dated 23 May 2026 (Job R18052627440211) proposes replacing the same 3-meter copper pipe I already paid for during the original installation, plus a fresh gas charge, for Rs 6,068 net of a 15% goodwill discount.
This is, on its face, an installation defect by Panasonic's previous authorised agency, certified in writing by Panasonic's current authorised agency. It is the same category of issue as the loose-screw relay failure: damage caused by deficient work in Panasonic's authorised network, not by normal use.
The three refrigerant top-ups across June 2025, October 2025, and March 2026 were closed without correctly diagnosing the underlying cause. Under the Consumer Protection Act 2019, that pattern is itself a deficiency in service, independent of warranty expiry. The defect existed during the warranty period; only the diagnosis came after.
The Inconsistency I Am Asking You to Resolve
On the same unit, in the same month, two consequences of the same network's poor work were identified:
The underlying principle should be the same in both cases. I am asking that it be applied the same way.
A Parallel Brand Reference (for context)
During the same period, I purchased a Voltas 1 Ton 5 Star AC, installed by the same Kharadi-based agency, which exhibited similar issues. Voltas's response was to replace the unit, carry out a fresh installation through a different agency, and discontinue their contract with the original installer. That unit has functioned without incident since. I understand that Panasonic has separately discontinued its contract with the same Kharadi agency, which suggests internal agreement that the agency's work was substandard.
Requested Resolution
I would prefer to resolve this directly with Panasonic. I am proposing three options, any of which I would accept as fair, in the same spirit in which the relay issue was handled:
Existing Record
This case is on record with the National Consumer Helpline as Grievance No. 9372662 (Status: In Process). I have also commissioned an independent technical assessment of the installation for the consumer record.
If a substantive response is not received within 7 working days of this email, I will be compelled to file before the District Consumer Disputes Redressal Commission, Pune, with the full documentary record: the relay precedent (which goes directly to the brand's own established standard of conduct), the Reliable Care Solution estimate, all five service tickets, photographic and video evidence, the Voltas reinstallation letter, and the independent technical assessment.
I would much prefer to continue as a Panasonic customer and resolve this directly, consistent with how the relay issue was already handled. Please direct your team to revert with next steps.
Sincerely, Dhiraj Thakur Kharadi, Pune +91 9987062806
Attachments:
Here is the complete report
https://htmlpreview.github.io/?https://github.com/Mosaic-agent/Mosaic-fund-agent/blob/main/output/inr_hedge_report.html
It also has recommendation.
Note its only for education purpose.
Every other week someone posts a new AI SRE project. You dig into it and it's the same thing - alert fires, shove logs into an LLM, get a suggestion. Demo looks great, try it on anything real and it falls apart.
I think the problem is nobody is solving the boring part first. Most places I've seen don't even have proper SLAs, forget SLOs. The infra knowledge lives in people's heads. So when something breaks the first question is always "okay but what does this service actually talk to" and nobody has a clean answer.
I've been thinking about building something that focuses on that problem specifically - building a graph of how your system actually fits together. Not a CMDB, those are always out of date. Something that continuously pulls from AWS APIs, your IaC, git history, service mesh telemetry, and keeps a live picture of what depends on what. So when a PR merges or a deploy happens you actually know the blast radius before someone pages you at 2am.
The LLM part should come after that - and it should be working on a small targeted context the graph gives it, not raw logs. Had a colleague recently debug a build failure by just passing the full log to Claude. Cost him $2-3 per run. That's just bad architecture masquerading as AI.
Curious if anyone has tried to build something like this internally, even partially. And what's the data source you wish you had during incidents that you just... don't.