The guiding rule we have is "if it's worth talking about .. then put it in the book so that we can all share it".
The regulator, in our case, has a bunch of rules but, overall, their main concern is that things are open, sensible, and reasonable while being consistent with the rules.
The recent history of faults will not always be in the book
that's your first, MAJOR, problem
hence the backdoor methodology.
understood .. but it ought NOT to be necessary to go to such lengths to achieve a simple goal
If you have a problem with a major item ... the 'black or white' requirement for the techlog dictates that the fault cannot go in the techlog.
if your rules require such an approach then your rules are a tad silly. The reality is that things range from black through grey to white and whatever system you have has to recognise and handle that in some rational way if it is to be credible.
If the system lies outside the MEL (as most major items are) you will end up with a grounded airframe.
I think that you are being a little too literal with respect to the intent of the MEL. Used appropriately, the system should work more flexibly than you are suggesting. Then again, I write our MEL so I make it reasonably flexible.
the MEL cannot deal with such instances
you are trying to twist the MEL to your perception. Just call the particular system U/S and then the MEL can deal with it just fine. If that means that the bird ends up sitting on the ground .. then maybe you didn't really want to fly with that glitch ?
you will just get a T.F.S. and a needless delay to the next flight
.....
They would blow a fuse - "you cannot put that in the techlog".
that sounds to me like the flight standards, maintenance, and tech service engineering folk need to sit down over a coffee or 20 and refine the system to remove its dysfunctionality
sounds like a good system - how do you do it
simple .. in the acquitting of the snag in the techlog, the maintainer puts words at the end to suit the occasion .. such as "Further pilot reports requested". Very much a case of tailoring the words to suit the occasion. Keep in mind that we use the system as both an airworthiness system record and a day to day functional communications tool between the drivers and the maintainers and that communications tool goes both ways.
how do you ensure that the 'hierarchy' actually pass it on?
I have no functional management control over the flightcrews. However, in the present system, the flying organisation is hierarchical and I am quite comfortable that, barring the odd foul up (and we are all prone to those), the message WILL get across to the line pilots. The system is pretty open and communicative and the flight standards management folks are well motivated in my view.