Why are 3 days required to identify a good connection?

[#1]

Every so often my IP profile gets reduced because the monitoring system wrongly decides that a disconnect can only indicate a poor quality of wiring.
In my case, the reason has hardly ever been attributable to a poor quality of wiring, eg. router reboot, ISP load balancing, power outage or SNR reduction by BT.
If one of these disconnects takes place after dark, then it is likely that the post connection sync speed will be lower than normal and so a further reboot will be required during daylight to try and get a good sync speed again. However, this extra disconnect event only increases the risk of a system interpretation of a bad quality of connection.
I know when the quality of my connection is consistent and that if the profile hadn't been reduced by the actions of the monitoring system, then my connection would be able to handle the speed. However there is a minimum of three days to wait before the automated systems start to recognise what has been true all along.
Would it be possible to have a flag that could be set on a connection that might set the monitoring system into a test mode?
That test mode would have the function of ignoring any disconnects one hour before or one hour after enabling test mode.
Test mode would also automatically stop after a period of one hour and could not be set again until a further three hours have passed (to prevent over use).
Then, if a customer has a planned disconnect, they could enable test mode, then carry out their actions without the concern of this being misinterpreted by the monitoring systems.
If an unplanned disconnect occurs and can be quickly determined to have a cause unrelated to the quality of the ADSL, then the customer could switch on test mode and it could retrospectively ignore the recent disconnection.
The one occasion when I have had to wait less than 3 days was some time ago, when I had a faulty telephone handset. The sync speed rapidly dropped to the minimum possible, followed shortly by the IP profile. Then when I detected and removed the faulty telephone handset, the sync speed and IP profile were restored within hours. So, the system can already recognise rapid recovery scenarios.

[#2]

I have the same problem and have been doing some research (whilst bored at work on Sunday  ) and it would appear that we are all restrained by the monopolistic organisation known as BT and their (poor and outdated...) infrastructure which appears to be very inflexable and will reduce an IP profile as quickly as it can, yet it takes 3 days to put it back up!
I have recently purchased the Netgear DGN2000 and have been using some "Routerstats" sofware from http://www.vwlowen.co.uk/internet/files.htm ; (found on fantastic ADSL resource site www.kitz.co.uk). ; This software has enabled me to find out that at 19:51 precisely every day there is a massive increase in my SNR level which often results in my router having to resync with the exchange, thus over time reducing my IP Profile.  I have no idea what it is as it could be anything along the 6-7km phone line (but certainly nothing at home, or with the neighbours). I would love to know the route it takes back to the exchange so I could investigate. The distance the line takes is more than twice the distance by road.... (does anyone know how to find the cable run route out?).  It is really frustrating having a long line with low IP profile that is so restrictive. I am hoping that upgrading my line to the ADSL2+ trial may give me a small but welcome boost.  The only way anything will ever dramatically increase is when (if) BT roll out FTTC or FTTP....

[#3]

@Ashgeo - Being realistic, the only improvement that you are likely to see from moving to ADSL2+ with a line of your length will be to the upstream speeds.
@JohnJ - I'm afraid my answer to your main question is along the lines of "because it is".  Ultimately, it's the way that the BT system was designed from IPStream Max onwards.  I don't know specifically why 3 days was chosen, but I'm afraiod that's how the system has always worked.

[#4]

Thanks Jamesh.
I had to ask as I'm afraid I can't help trying to think of continuous improvement.
If you ever hear of any workarounds or back doors to Skynet, please feel free to share

[#5]

Realistically, with both ADSL2+ now being live and FTTC/H starting, I wouldn't expect any further changes to IPStream Max.