Schedule A is the Oracle ordering document that records what the buyer holds. It names every product, every metric, every quantity and every condition. The Admodum read on the document’s anatomy and the repackaging trap.
Schedule A is the Oracle ordering document. It sits beneath the master agreement (the Oracle Master Agreement or, on older contracts, the Oracle Licence and Services Agreement) and records the specific order: which products, in which metric, in which quantity, at which price, with which support attached.
The master agreement is a framework; it sets the licensing terms, the warranty position, the audit clause, the termination language, the choice-of-law and venue. Schedule A is the order; it instantiates the framework with the specific products, metrics and quantities the buyer is acquiring at the time of the order. The two documents together form the contractual position.
Every subsequent order adds another ordering document (Schedule A, Schedule B, ordering schedule, ordering document) to the contract record. The buyer’s position at any moment in time is the cumulative reading of every ordering document the buyer holds. The wider editorial sits in the Oracle pillar.
The product-list column on Schedule A names every Oracle product the buyer is acquiring at the order. Each row carries a product name, a part number, and (on older orders) a feature description. The product names are publisher-defined and tied to specific product families: Database Enterprise Edition, Database Standard Edition 2, Real Application Clusters, Partitioning, Diagnostics Pack, Tuning Pack, and so on across the catalogue.
Reading the product list against the deployed environment is the first compliance pass. Every deployed Oracle component must trace to a Schedule A row; any deployed component that does not trace is either unlicensed (an audit exposure) or licensed under a different contract instrument (an entitlement that must be cross-referenced).
The deeper read on options and management packs sits at database options and management packs.
The metric column is the load-bearing column. It sets how the deployment is counted against the licence. The two principal Oracle metrics are Processor (a per-core measurement with the core-factor multiplier) and Named User Plus (a per-user measurement with per-processor minima). A handful of products carry alternative metrics: application user (Oracle Applications), authorised user (selected middleware), employee (selected applications).
The metric is fixed at the order. The buyer cannot, after the fact, retroactively change the metric without a renegotiation. A perpetual licence acquired on the Processor metric is fixed against that metric for the life of the licence; the same is true for Named User Plus.
The deeper reads sit at the processor metric, at the named user plus metric, and at the core-factor table.
The quantity column names how many units of the product, in the named metric, the buyer is acquiring. For a Processor-metric licence, the quantity is the per-processor count after the core-factor multiplier is applied. For Named User Plus, the quantity is the named-user count.
The quantity is the entitlement. Deployments above the quantity are unlicensed; deployments below the quantity are unused entitlement (which has no recurring cost beyond the support fee but represents shelfware against a sunk perpetual cost).
The buyer-side discipline is the deployment census (point two of the renewal cycle). The census reads every deployed unit and reconciles against every Schedule A quantity; the output is the entitlement-versus-deployment delta by product and by metric.
The repackaging trap is the renewal moment where Oracle proposes a Schedule A movement: trade unused products for needed products, restructure the metric across product lines, or swap a Named User Plus position for a Processor position. The trap reads when the buyer accepts the movement without a one-for-one reconciliation against the original Schedule A.
The trap surfaces in two patterns. The first is silent dilution: the new Schedule A names quantities that look equivalent but carry different scope (a different metric, a different entity definition, a different geographic scope). The second is structural simplification: the new Schedule A collapses multiple line items into a single line that loses the granularity needed for a future deployment census.
The buyer-side discipline reads every Schedule A movement as a re-set of the contractual position, not as a clerical update. Each line is reconciled against the original; each scope change is named explicitly; the closing memorandum records the net effect. The deeper read sits at Schedule A repackaging.
What the buyer holds, at any moment in time, is the cumulative reading of every Schedule A and every subsequent ordering document. The contract map (point three of the renewal cycle) is the artefact that consolidates that reading; it lists every Schedule A by date, every product by line, every metric, every quantity, every support attachment, every special clause.
The contract map is the load-bearing artefact at the renewal table. It is the artefact against which every publisher proposal is read. The buyer-side discipline is to refresh it before every renewal, every audit response, every new ordering document; the publisher’s discipline does not refresh it for the buyer.
The aggregated reading list sits in the Oracle knowledge hub; the engagement entry point sits in the Oracle practice; the audit-defence programme sits at audit defence.
A senior Admodum Oracle advisor will read every ordering document the buyer holds and assemble the contract map on a private call. Active audit events route to the Audit Defence programme.