BCal help system: The Tutorial
As a result of this lack of data or prior information, the BCal software automatically selected a bound for this event which is considerably earlier than any of the calendrical information (radiocarbon or prior) that we provided in our project definition. This has the effect of permitting the simulated value for alpha 1 to vary enormously at its early end and hence gives precedence to the radiocarbon and prior information from the other parameters. Indeed, this is all that BCal can do with parameters at the early and late bounds of projects if we provide no prior information about their date. It is worth noting here, that we were able to provide precise prior information about the latest date at the fishpond (beta 2) and so we do not have the same problem at the late end of our sequence. At other sites, the same problem is likely to manifest itself at both ends of the sequence.
What we are saying here, is that BCal can only learn about calendar dates of parameters if there is prior information, radiocarbon data or both that relate closely to them. This is particularly important for parameters at the early and late extremes of our sequences. Without such information BCal simply uses these parameters to keep the simulation in approximately the right part of the calibration curve. As such we want the results of these parameters to be variable so that the simulation routines used for the other parameters can move over the entire temporal space appropriate for the site in question and be restricted only by the radiocarbon data and the prior information available from the site. In using early (and late) boundary parameters at a particular site in this way, however, we cannot expect to reliably learn about their dates.