ANSTHRLD - Re: Augmentation question(s)

[tmcd@jump.net]

With Alisandre's permission, I'm sending a private reply to the list.

On Fri, 21 Jan 2000, Amanda Lewanski <editor at texas.net> wrote:
> I'm honestly not trying to quibble, here, but isn't it really
> ordering the recipient what to do?

Why not quibble, if you would be a quibblard?  I quibble daily and
twice on Sunday.

Whoever gets the order, it's still the Crown ordering someone that
something heraldic be done in exactly the way they specify -- which
works as well as Canute ordering the tides, or to quote Shakespeare:
   "I can summon spirits from the vasty deep!"
   "Why, so can I, and so can any man.  But will they come when you call?"

> I'm still not terribly clear on why augmentations have to be
> registered at all--presumably the underlying arms are already
> registered and thus clear, and can adding something bring it into
> conflict with someone? Or are they registered to try to keep tabs on
> an appearance of presumption?

They are registered for the same reason anything else gets registered:
to get it in the Big Book-O-Heraldry, so it's Official, and scribes
can look it up for scrolls^W charters, and to make sure it's a
reasonably Good Thing heraldically speaking.

Adding something *can* cause conflict where there was none before.  As
a related example, there's a precedent where a Bellatrix of the West
added a label to his dad's arms and got a conflict where his dad
didn't have one:

    Indeed, we have a specific precedent: the device submission of
    Stephan of Bellatrix (Sable, on a bend Or three compass stars
    gules, overall a label argent).  The submission was his father's
    device plus a label; and the Clause permitted Stephan to ignore
    any conflicts that applied to his father.  But ``the Grandfather
    Clause cannot apply in cases where the submitted arms have a
    conflict to which the original device would not be subject.  Since
    his father's arms do not conflict with Carswell, but only his own,
    the Grandfather Clause cannot be applied here.''  [DiA, LoAR of
    Sept 91, p.20]

For example, Galen's current arms are
    Gules, a bend wavy between two double bitted axes or.
Suppose that there were a registered
    Gules, on a bend wavy between two eagles Or a mullet sable.
They would be clear: one CD for ax<->eagle, one CD for adding
something on the bend.  Galen's proposal of
    Gules, a bend wavy between two double bitted axes or, as an
    augmentation on the bend a mullet of five greater and
    five lesser points sable.
would then conflict: still one CD for ax<->eagle, but you need two
changes to a charge-on-charge to get a CD.

Further, conflict isn't the only thing checked in registration.  All
the style rules have to be followed too.  If someone wanted as an
augmentation "on a canton argent a tower Or", it should be returned
for contrast.  If someone wanted an augmentation of the arms of
Scotland, that should be returned for appearance of pretense.
Augmentation can get some slack in a few rules.  For example, an
augmentation inherently adds complexity, so the rule-of-thumb
complexity gets loosened for them.  However, it doesn't mean carte
blanche to have whatever one likes.

There's a Bruce prec. that applies somewhat for conflict, and why you
want to protect both versions:

    Augmentations in Society armory should always be blazoned as such;
    the bearer has the option of displaying the armory with or without
    the augmentation, and conflict should be checked against both
    versions.  (Rondallyn of Golgotha, September, 1992, pg. 26)

> I thought I remembered there was some question on the inescutcheon
> as a form of display for an augmentation, and it was decided it was
> okay.

You remember correctly.  There was a Bambi precedent that read

    The use of the inescutcheon here for the augmentation would seem
    to be prohibited by the ban on appearance of pretense in AR10d:
    note that such usual insignia of augmentation as chiefs, cantons,
    bases are not included here.  (LoAR Aug 88, p. 16)

but that was changed in or before the return of Jan's first augmentation:

    [An augmentation of an inescutcheon in honor point, bearing the
    arms of an SCA barony] "While most of the College, and Laurel
    himself, has no problem with the use of an escutcheon as a vehicle
    for an augmentation {if I may quote Lady Harpy: 'the whole point
    of forbidding the charging of inescutcheons and cantons in a way
    that resembles an augmentation is so that you can do it when you
    want an augmentation.'}

> Anyway, don't some kingdoms have a standard form for the kingdom's
> augmentation, and when you get an augmentation you get X (or was
> that just a proposal that didn't fly, which I am dimly
> remembering?)?

There was a ducal augmentation for Ansteorra, but it was released.  I
recall running across a standard augmentation for Atenveldt today, but
I can't find it.  I do find, 3/96:

    Meridies, Kingdom of.  Augmentation.  [Fieldless] Three mullets
    one and two argent.
        This is an augmentation of arms which the Crown of Meridies
        may grant to individuals it deems worthy.  Its purpose is not
        the same as a fieldless badge; as an augmentation, it should
        always be displayed on a field by the recipients.

The resulting coat still has to be checked on a case-by-case basis to
be registered.  However, there is a benefit to registering the
augmentation alone.  The proposed rule change codifies something that
I think is already in precedent:

     If an augmentation has the appearance of being independent
     armory, for example a charged escutcheon or canton, then it is
     independently subject to the normal rules of armorial conflict.

This registration for Meridies gives some protection, to prevent some
conflicts that might arise under this rule.

Daniel de Lincolia
--
Tim McDaniel (home); Reply-To: tmcd at jump.net;
if that fail, my work address is tmcd at us.ibm.com.

============================================================================
Go to http://lists.ansteorra.org/lists.html to perform mailing list tasks.