Several of these words mean something more specific in MTC Skopos than they do in ordinary SAP usage. The two that cause the most confusion are action and system, and both are worth reading before writing a ruleset.
Ruleset terms
Ruleset — The table defining what counts as a risk, loaded from an XLSX worksheet or a CSV. One row per authorization value. Yours to write and maintain; nothing ships with the product.
Worksheet name — For an XLSX ruleset, the sheet holding the rules. Typed on import and matched exactly. Only that sheet is read.
Risk — A named condition that is undesirable, identified by an Access Risk ID. A Segregation of Duties risk needs two or more conflicting functions; a critical access risk needs one.
Function — A logical business capability, grouping the actions and permissions that let somebody do a thing. Functions are the building blocks a risk is composed from.
Action — A permission group, not a transaction code. This is the term most often misread. An action groups the permissions that are all required together, as a logical AND, to exercise it. An action named VK11 does not check that the user can run transaction VK11 unless the S_TCODE authorization object is listed among its permissions explicitly.
Permission Object — An authorization object. Every object under the same action is required together.
Field — An authorization field within an object. Every field under the same object is required together.
Value From / Value To — A value or an inclusive range. Multiple values for one field combine per the Condition column.
Condition — AND or OR, governing multiple values for the same field. Mixing both means every AND value is required plus at least one OR value.
Placeholder — A token such as $BUKRS in a ruleset's System or value columns, bound to concrete values at analysis time through organizational scopes.
System (in a ruleset) — Where the function is expected to be exercised. Must match a data source name exactly and case-sensitively. A mismatch is the most common cause of an analysis that returns nothing.
Access model terms
Single role — A role carrying authorizations directly.
Composite role — A role that bundles single roles and carries no authorizations of its own.
Master and derived role — A derived role inherits its authorizations from a master and differs only in organizational values. Editing the master affects every derived role, which is why the distinction matters before proposing a change.
Profile — The older SAP mechanism for granting authorizations. A profile assigned directly to a user, rather than through a role, is invisible unless UST04, UST10S, UST12 and AGR_1016 are all loaded.
Business role — An IAM-layer bundle pointing at ERP roles in one or more systems. Carries no permissions itself; its access is whatever its member roles grant. See IAM Business Roles Import.
Fiori app — An application identified by an app ID rather than a transaction code. Usage data for Fiori is frequently absent, which is why remediation excludes Fiori apps by default.
Identity terms
Local user — An account name as it exists in one system.
Canonical user — The person an account belongs to, across systems. Supplied through a USER_CANONICAL_MAPPING file. Without mapping, each local account is its own canonical identity.
Reports carry both: User ID is canonical, Local User ID is the account. They differ only where mapping applies. See Cross-System Analysis.
Analysis terms
Users analysis — Evaluates conflicts arising from the combination of roles a person holds. Answers who has a problem now.
Roles analysis — Evaluates conflicts built into a role's own contents, independent of assignment. Answers which designs will keep producing problems.
Criteria — The scope of a run. Mandatory: an unselected filter excludes everything rather than including everything.
Cross-system analysis — Evaluates a person's combined access across several systems, so a conflict split between two systems is detected. Requires canonical mapping.
Did-Do — Evidence that access was actually exercised, from usage statistics and SAP change documents, as distinct from access merely held.
Simulation — Applying hypothetical changes to a run so results show what would happen. Results classify as Added, Removed, or Unchanged against the unsimulated state. Nothing is written to any source system.
Organizational scope — A binding of ruleset placeholders to concrete values. Unlike a filter, which removes rows from a result, a binding changes what counts as a risk: a conflict is reported only where both functions are exercisable within the same scope.
Risk exclusion — A formally accepted user-and-risk or role-and-risk combination, left out of a run when the criteria enable exclusions. Recorded in the execution log, so the evidence states that exclusions were applied.
Output terms
Summary report — One row per entity and risk. The working list.
Detailed report — One row per authorization contributing to a conflict. The evidence layer, and much larger.
Execution log — The signed .log written alongside the reports, recording criteria, ruleset checksum, and a checksum and row count for every table. What makes the reports audit evidence rather than a spreadsheet.
Complexity — Easy, Medium, Hard or Very Hard, rating the effort and blast radius of applying a recommendation.
Non-repudiation signature — A second signature applied with your own key (BYOK), proving your organization signed the log, as distinct from the embedded key which proves MTC Skopos produced it. See Bring Your Own Key.