KF-3008 · Architectural Authority Framework

How authority is established, exercised, delegated and evidenced within a governed knowledge system

Reference Architecture · Draft · v0.1 · 23 min read

Principle (KF-1000) → Lifecycle (KF-2001) → Materiality (KF-2003)
        → Reference Architecture (KF-3000)
              → Architectural Integration Model (KF-3006)      ← how the architecture behaves
              → Architectural Conformance Framework (KF-3007)  ← how that behaviour is evaluated
              → ▸ Architectural Authority Framework (KF-3008)  ← who may make it consequential
        → Implementation (KF-4000)

Throughout the architecture the programme has used words that presuppose authority — actor, reviewer, approver, owner, authority, acceptance, delegation, accountability — without ever defining authority as an architectural construct. That omission is the last remaining gap in the conceptual core, and it matters because Knowledge Foundry is fundamentally about institutional knowledge, and institutional knowledge cannot exist without institutional authority.

This document is therefore not about organisational hierarchy, and it is emphatically not an access-control document. It answers one question:

Who possesses the architectural authority to create, evaluate, accept, modify, supersede and retire Operational Knowledge ObjectsOperational Knowledge Object — the unit of design: a versioned representation together with its attached evidence, justification and acceptance-state (KF-1101). The system governs the object, never "knowledge itself". Vocabulary → — and how is that authority established, exercised and evidenced?

It is titled a Framework, not a Model, because it establishes governing rules, not merely a description of relationships.

Purpose

The Architectural Authority Framework defines how authority is represented, exercised, delegated and evidenced within the Knowledge Foundry Reference Architecture. It establishes the architectural rules governing who may perform consequential lifecycle actions, under what conditions those actions are legitimate, and how authority itself becomes observable through traceable evidence.

The document is about authority itself — not organisational charts, and not the technologies that authenticate people or enforce permissions. Where KF-3006 asked how the architecture behaves and KF-3007 asked how that behaviour is evaluated, KF-3008 asks who possesses the legitimate authority to make that behaviour consequential. Without it, acceptance — the act at the centre of the lifecycle — remains an abstract concept with no defined source.

Read together, these three documents answer three complementary questions — which is why they are three documents and not one long chapter:

Figure 1 · Why Authority Belongs in the Architecture

Worked example. KF-5001 §5 shows a real acceptance — who held the authority, and how it resolves from decision back to institution.

Institution
     ▼ constitutes
Governance
     ▼ defines
Role
     ▼ carries
Authority
     ▼ legitimises
Decision
     ▼ effects
Lifecycle Transition
     ▼ emits
Evidence
     ▼ warrants
Institutional Reliance

Read top to bottom, the figure explains authority’s architectural purpose in a single line: an institution constitutes governance, which defines roles, which carry authority, which legitimises the decisions that effect lifecycle transitions, which emit the evidence that warrants an institution in relying on what it knows. Authority is the link without which reliance has no legitimate source.

Scope and the Authority Admission Test

KF-3008 is technology-neutral and institution-neutral. It defines architectural authority; it does not name the mechanisms that implement it. A statement belongs in KF-3008 only if:

1. it concerns the establishment, exercise, delegation, scope, failure or evidence of architectural authority;
2. it can be stated without naming a specific technology, product, directory or protocol; and
3. it references elements defined elsewhere in the programme without redefining them.

Deliberately out of scope, because it belongs to implementation (KF-4000): Active Directory, IAM, OAuth, RBAC schemes, authentication, credential and permission stores. Also distinct is technical permission — the architectural ability to execute an action — which is owned by the Access and Integrity Service (SVC-16). This framework governs institutional authority (the right); SVC-16 governs permission (the ability); KF-4000 implements both. Authority is not permission (KF-3001 IC-13), and this document never conflates them.

1 · Introduction

1.1 Purpose

To define authority as a first-class architectural construct: what it is, who holds it, how it is bounded and delegated, how it fails, and how it is made observable — so that every consequential act in the lifecycle resolves to a legitimate, attributable and reconstructable authority.

1.2 Scope

In scope: the philosophy and principles of authority; the distinction of authority from responsibility, accountability, ownership and permission; the authority model; authority types, scope and lifecycle mapping; delegation; authority evidence; separation of authority; the interaction of authority with materialityMateriality — the degree to which an object, claim, decision or transition may affect consequential action, reliance, obligation, exposure, representation or preservation (KF-2003). Vocabulary →; authority failures; continuous authority; and the concept of institutional reliance.

Out of scope: organisational design and staffing; access-control and identity technology (KF-4000); the substantive content of governance policy; and the definition of any lifecycle stage, control or record (their home documents).

1.3 Relationship to the Canon

Authority is the architectural realisation of Principle III — knowledge becomes enduring capability only through collective authorisation — and of the human-accountability invariant: labour may be distributed across people and machines, but accountability may not be discharged into a substrate (KF-1103; KF-1050). This framework fixes where that irreducible human authority sits and how it is exercised.

1.4 Relationship to Lifecycle

The lifecycle names an Authority role and an Accept transition and insists that acceptance is an act of authority distinct from justification (KF-2001). KF-3008 defines the authority that the Accept transition — and every other consequential transition — requires. KF-3005 identifies these needs abstractly, as Required Authority Class, Required Decision Role and Required Separation Condition in its Transition-to-Authority Crosswalk (§60); KF-3008 defines who may occupy those roles.

1.5 Relationship to Conformance

Authority is itself assessable. KF-3007 lists an Authority conformance dimension; this framework supplies what that dimension tests — was authority valid, was delegation valid, was acceptance legitimate, can authority be reconstructed? (§15). Because authority is evidenced event-natively (§10), it is demonstrable on the same terms as everything else the architecture does.

2 · Philosophy of Authority

Before the principles, one distinction frames them. Authority establishes who may perform a consequential act; legitimacy concerns whether that act satisfies the architectural conditions governing its exercise. A decision may originate from a valid authority yet still fail to achieve architectural legitimacy if required obligations, controls or evidence are absent — just as a technically sound recommendation from an unauthorised source never acquires authority at all. Authority is the entitlement; legitimacy is the entitlement properly exercised. This framework defines authority; legitimacy is what the Conformance Framework (KF-3007) later assesses, which is why an “authority valid” finding and an “act legitimate” finding are distinct there.

Authority in Knowledge Foundry rests on nine convictions.

1. Authority exists to protect institutional reliance. It is not an administrative convenience; it is the mechanism by which an institution may legitimately base action on what it knows. Authority exists because institutions rely — not the other way around.
2. Authority is vested in institutional roles, not individuals. A role carries authority; individuals exercise it only by virtue of occupying the role. People join, move and leave; the authority persists in the role and the institution.
3. Authority is attributable. Every exercise of authority resolves to an identified role and, through it, an identified person or accountable body. No consequential act is anonymous.
4. Authority is bounded. No authority is universal. Every authority has a scope beyond which it does not reach (§7).
5. Authority is delegable — under rule. Authority can be extended to others through governed delegation, without losing attribution or accountability (§9).
6. Authority is observable. Authority that cannot be seen cannot be relied upon; it must leave evidence of its mandate, its exercise and its bounds (§10).
7. Authority is revocable. Authority can be withdrawn, and withdrawal must not retroactively invalidate acts legitimately taken while it held (§14).
8. Authority is proportional to materiality. The authority required to make an act consequential rises with the reliance placed on it (§12). The invariant that some human authority is required never varies; the level of authority does.
9. Authority is persistent, not personal. Because institutional knowledge must survive personnel change, authority belongs to the institution through defined governance structures rather than to particular people. An individual’s departure ends their exercise of authority; it does not remove the authority, which remains vested in the role and reconstructable in the record (§14).

3 · What Is Architectural Authority?

Architectural authority is the legitimate institutional right to make a knowledge act consequential — to cause a lifecycle transition on which the institution will rely. It is distinct from five concepts with which it is routinely confused. The architecture keeps all six apart.

The confusions this dissolves are load-bearing: ownership does not imply authority (a Steward maintains an object but may not be the accepting Authority); permission does not imply accountability (a service may be permitted to execute a transition an agent proposed, while accountability remains with a human); responsibility does not imply acceptance authority (an Evaluator is responsible for the verdict but does not thereby accept the object); and expertise does not imply authority (an expert may hold no acceptance authority, while an executive may hold acceptance authority without being the technical expert). The architecture keeps informed judgement separate from the entitlement to act on it. Acceptance is the exclusive province of Authority.

4 · Authority Principles

Every authority in the architecture shall be:

• explicit — recorded as a mandate, never assumed from position or context;
• attributable — resolvable to an identified role and person or accountable body;
• bounded — scoped by domain, stage, object type, materiality, organisation, jurisdiction and time (§7);
• proportional — sufficient for the object’s assurance classAssurance class — the ordinal grade (A0 Exploratory · A1 Working · A2 Routine · A3 Consequential · A4 Critical) that sets the depth of assurance required; attaches to the release / scope of reliance (KF-2003). Vocabulary →, and no broader than needed (§12);
• reviewable — subject to periodic confirmation and re-validation;
• traceable — evidenced such that any exercise can be reconstructed (§10);
• durable across organisational change — vested in roles and the institution, so that departures and reorganisations do not orphan authority or void its history (§14);
• technology-independent — defined without reference to any authentication or permission technology.

5 · The Authority Model

The heart of the framework. Authority flows through a chain from the institution to a specific lifecycle action:

Institution
     ▼ constitutes
Governance Structure
     ▼ defines
Role
     ▼ carries
Authority
     ▼ permits
Permitted Decisions
     ▼ effect
Lifecycle Actions

The decisive property is stated once and holds throughout: authority is vested in institutional roles, not people; individuals exercise it only by virtue of occupying those roles. An institution constitutes a governance structure; the governance structure defines roles; roles carry authority; authority permits particular decisions; those decisions effect lifecycle actions. Individuals occupy roles and thereby exercise — but never own — the authority a role carries. This is what lets a governed knowledge systemGoverned knowledge system — a socio-technical system that holds operational knowledge objects and governs their transition from one justified state to another across modalities (KF-1001). Vocabulary → survive personnel change without losing the legitimacy of its past decisions: the person who accepted an object may leave, but the role that accepted it, and the institution behind the role, remain.

An accountable body (a board, a committee, a named office) is modelled as a role held collectively. Collective authority is still attributable — to the body, and to the members who acted — and still resolves to identifiable humans, satisfying Principle III.

5.1 Authority Resolution

Every consequential act must be able to answer one architectural question: from where did this authority originate? Authority resolution is the authority equivalent of traceability — the reverse reading of the model chain, from an act back to the institution that ultimately warranted it.

Decision
     ▲ resolves to
Authority
     ▲ carried by
Role
     ▲ defined by
Governance Structure
     ▲ constituted by
Institution

Where traceability reconstructs what happened and why, authority resolution reconstructs by what right. A consequential act whose authority cannot be resolved to a role, a governance structure and an institution is not legitimately authorised, however competent the actor — and the failure is detectable (§13: ambiguous or orphaned authority). Resolution is graded like everything else: the depth to which authority must be resolvable rises with assurance class (§12), and it is demonstrated from the mandate, delegation and decision records the act already emitted (§10).

6 · Authority Types

“Approver” is too coarse. The architecture distinguishes authority by the consequential act it legitimises; each type has a distinct architectural meaning and attaches to a distinct transition.

Acceptance, Publication, Supersession and Retirement authorities are the consequential ones: they must resolve to an identifiable human authority and may never be discharged into a substrate (KF-3006 §5.3). Creation and Evaluation may be agent-assisted under a named role. Delegation authority is meta-authority — the authority to confer authority — and is the most tightly bounded of all.

6.1 Authority Relationships

Authorities do not act in isolation; they stand in defined relationships to one another. Naming these relationships is the bridge from what authorities exist to how far each reaches (§7):

• authority may delegate authority — conferring a bounded portion on another role (§9);
• authority may require concurrence — a decision needing two or more authorities acting together before it takes effect;
• authority may require independent review — an act valid only once reviewed by an authority outside the deciding role (§11);
• authority may supersede authority — a higher or later mandate displacing an earlier one, with lineage preserved;
• authority may be constrained by policy — a governance rule narrowing what an otherwise-valid authority may do;
• authority may be suspended — temporarily rendered unexercisable pending review, without being revoked (§13).

These relationships are themselves governed and evidenced: a concurrence, a required review, a supersession or a suspension is recorded as it happens, on the same event-native terms as any other authority act (§10). They are the vocabulary in which the scope rules of §7 and the separation pattern of §11 are expressed.

7 · Authority Scope

No authority is universal; scope is what makes it bounded. An authority is defined over one or more dimensions, and an exercise outside its scope is not weak authority but no authority.

Scope is recorded with the mandate and checked at every gate. An acceptance authority valid for A2 Routine objects in one domain does not thereby authorise an A3 Consequential object, an object of another type, or an object outside its effective period. This is how the architecture prevents unlimited authority without enumerating every permitted act.

8 · Authority and the Lifecycle

Authority maps onto the lifecycle transition by transition. Each consequential move is gated by the authority type it requires:

Candidate ──(Creation Authority)──▶ admitted
     ▼
Evaluated / Justified ──(Evaluation Authority)──▶ verdict certified
     ▼
Accepted ──(Acceptance Authority)──▶ reliance authorised
     ▼
Operational ──(Publication Authority)──▶ eligible in scope
     ▼
Next Version ──(Revision Authority)──▶ change authorised, warrant re-earned
     ▼
Superseded ──(Supersession Authority)──▶ successor installed, lineage preserved
     ▼
Historical ──(Retirement Authority)──▶ active life ended, history intact

This is the concrete filling of KF-3005’s abstract Transition-to-Authority Crosswalk (§60). A transition presented without the authority its gate requires does not proceed; the gate returns Fail or Not Assessable, never a silent Pass (KF-3005; KF-3007 §13).

9 · Delegation

Delegation is how authority extends beyond a single role-holder without loss of attribution or accountability. The architecture recognises seven distinct constructs, and conflating them is a common source of authority failure:

• Delegation — a role-holder confers a bounded portion of its authority on another role, for a defined scope and period; accountability remains with the delegator.
• Substitution — a temporary stand-in exercises a role’s authority in the holder’s absence, under the same bounds.
• Escalation — an act requiring authority beyond the current holder’s scope is routed upward to a role that holds it.
• Revocation — conferred authority is withdrawn before its natural expiry, by an attributable act (§14).
• Expiry — conferred or temporary authority lapses at the end of its effective period without further action.
• Temporary authority — authority granted for a bounded period or purpose, expiring automatically.
• Emergency authority — an exceptional, time-boxed grant permitting action under urgent conditions, recorded as a governance exception and visible until reviewed (KF-3001 IC-19); it may never waive an invariant.

Every delegation is itself an exercise of Delegation authority (§6), bounded by scope (§7) and evidenced (§10). Delegated authority can never exceed the delegator’s own scope: one cannot confer what one does not hold.

10 · Authority Evidence

The framework’s connection to KF-3007: authority itself becomes evidence. Because authority must be observable (Principle 6), every mandate, delegation and exercise leaves a record — not because any particular technology requires it, but because the architecture requires authority to be reconstructable.

Authority is evidenced through records the architecture already maintains (KF-3004): the Authority Mandate Record (AUT-01) and Delegation Record (AUT-02), maintained by SVC-06; the Acceptance Record and Scope-of-Reliance Record; role-assignment records; and the decision and transition records emitted by every gated act. In implementation these may take the form of an approval record, a signature, a delegation entry, a role assignment, an acceptance event or a decision log — but the architecture requires only that the mandate, its bounds and its exercise be recoverable.

This evidence is event-native (KF-3001 IC-24; KF-3004 §5.2): the acceptance record is the evidence that acceptance authority was exercised; the delegation record is the evidence that delegation was valid. Authority does not commission a separate register of its own legitimacy; the exercise of authority generates its evidence as a natural consequence of the architectural event rather than through a parallel administrative process (KF-3006 §9), exactly as the rest of the architecture does.

11 · Separation of Authority

Some acts should not be authorised by the same role that produced the work. The architecture recognises separation as a pattern, applied where materiality warrants rather than mandated everywhere:

• Evaluator ≠ Approver — the role that certifies a verdict is not the role that accepts reliance on it;
• Author ≠ Reviewer — the role that produced content is not the role that reviews it;
• Publisher ≠ Accepting Authority — the role that releases into operation is not the role that accepted the version.

Whether separation is required is a function of assurance class (§12): Exploratory and Working objects may collapse these roles; Consequential and Critical objects increasingly require them, enforced by the Separation-of-Duties control (CTRL-SEG-01). Separation is thus proportional, like everything graded in the architecture — a floor that rises with reliance, not a uniform burden.

12 · Authority and Materiality

Authority is one of the quantities materiality grades. The bridge to KF-2003 runs:

Materiality (of the intended reliance)      ── KF-2003
     ▼ determines
Assurance Class   (A0 … A4, + overlays)
     ▼ sets
Required Authority   (which type, whose confirmation, what separation)
     ▼ produces
Evidence   (mandate, delegation, acceptance — event-native)
     ▼ enables
Conformance   (the Authority dimension — KF-3007)

Concretely: the object owner proposes an assurance class; for A3 and A4 the governance authority confirms it (KF-2003 §7). Higher classes demand higher and, where the pattern applies, separated authority; A4 Critical typically demands a formally constituted accountable body and independent review. The universal floor never moves — some identifiable human authority is always required — but its level, formality and separation rise with reliance. Automation may recommend a class or propose a transition, but may not hold the confirming authority for consequential or critical objects (KF-3001 IC-16).

Authority scales with consequence, not seniority. Higher materiality does not necessarily demand a more senior individual; it demands authority appropriate to the consequence and scope of reliance. Seniority and authority often coincide in practice, but the architecture equates required authority with the reliance at stake, never with rank: an A4 acceptance needs an authority mandated for A4 consequence in that domain and scope, which may or may not be the most senior person available. Equating authority with hierarchy is a category error the scope rules of §7 exist to prevent.

13 · Authority Failures

Treating authority architecturally means naming how it fails. Each failure is a detectable condition with an architectural consequence, not merely an operational inconvenience.

None of these is resolved by proceeding. An authority failure yields a governed outcome — block, refuse, suspend, escalate or record an exception — and never a silent transition.

14 · Continuous Authority

Authority is dynamic. Organisations restructure; roles are created and dissolved; people are appointed and depart; delegations are granted and revoked. The architecture treats authority as a living state, subject to continuous validation — and it holds one rule above all the churn:

A change in authority never invalidates historical evidence.

An acceptance made by a role that later ceased to exist remains a valid acceptance: it was legitimate at the time it was made, and the record carries the effective time at which the authority held (KF-3004 time semantics). Revocation, departure and reorganisation act forward, on future exercises of authority; they do not reach back to void past acts or erase the lineage of decisions already taken (the lineage invariant, KF-2001). This is what allows an institution to reconstruct, years later, that a decision was properly authorised when it was made, even though every person and role involved has since changed. Continuous validation keeps present authority current; append-only history keeps past authority true.

15 · Relationship with Conformance

Authority is assessable on exactly the terms KF-3007 defines. The Authority conformance dimension reconstructs, from event-native evidence, the answers to four questions for any consequential act:

• Was authority valid? — did a mandate exist, in scope and in its effective period?
• Was delegation valid? — did any delegation stay within the delegator’s bounds?
• Was acceptance legitimate? — did the accepting authority hold sufficient authority for the object’s assurance class?
• Can authority be reconstructed? — to the depth the class requires, can the whole chain from institution to act be recovered?

A “no” to any is a finding (KF-3007 §13), graded by materiality. Because authority is evidenced natively, these questions are answered from the record the act already produced — assessment reads authority, it does not re-interview it.

16 · Summary

Authority is not an administrative convenience. It is one of the architectural mechanisms through which institutional trust becomes possible. This framework:

• defines authority as the legitimate right to make a knowledge act consequential (§3), distinct from responsibility, accountability, ownership and permission;
• vests it in roles, not people (§5), so it survives organisational change;
• distinguishes authority types (§6), scope (§7) and failures (§13);
• maps it onto the lifecycle (§8) and governs its delegation (§9);
• makes it observable and event-native (§10), separable where materiality warrants (§11), and proportional to assurance class (§12);
• keeps it continuous without letting change rewrite history (§14);
• and renders it assessable on the same terms as every other architectural behaviour (§15).

Above all it defines the concept that gives authority its purpose: institutional reliance. Institutional reliance is the explicit willingness of an institution to base decisions, actions or obligations upon an Operational Knowledge Object. Authority exists because institutions rely — and this framework is how that reliance acquires a legitimate, attributable, reconstructable source.

Relationship to Subsequent Documents

• KF-3009 · Architectural Crosswalks and Traceability carries the authoritative tracing from Canonical PrincipleCanonical Principle — an enduring obligation true of any governed knowledge system, admitted only if it survives the two-question test (KF-1000 Part III). Vocabulary → III and the human-accountability invariant through the authority types, scopes and controls named here.
• KF-4000 · Knowledge Operating System implements authority — identity, authentication, permission and delegation technology — within the architectural rules this framework fixes, and never in place of them.

Closing Statement

Across the KF-3000 series a three-layer structure has completed. KF-3000–3005 are the structural architecture — what exists. KF-3006 and KF-3007 are the behavioural architecture — how it behaves and how we know. KF-3008 is the institutional architecture — who may legitimately make that behaviour consequential. A knowledge architecture that can only represent and process knowledge is a sophisticated knowledge system; it becomes a framework for governed institutional knowledge only when it can establish who has the legitimate authority to create, evaluate, accept and rely upon what it holds. That is the layer KF-3008 supplies, and with it the conceptual core of Knowledge Foundry is complete.

Status and Next Step

This document is Draft · Version 0.1. Its authority types, scope dimensions, delegation constructs and failure modes are exercised directly by the first vertical slice, whose A3 Consequential object requires a confirmed acceptance authority and, under §11, the beginnings of separation. The slice is the occasion on which this framework — like KF-2003 and KF-3007 — is first tested against a real object rather than asserted, and revised before the series is baselined.