Why certify by role

Seven roles, seven distinct skill sets

Book II (Framework Specification) defines five roles that keep the TEAF loop running day to day. The certification program extends that logic to two complementary roles — the link with the board and deployment at a client — rather than producing interchangeable generalists.

01

Architecture Owner

Owns the target architecture vision

Responsible for the overall consistency of a capability domain. Carries the legitimacy of the Decision Fabric within their scope and runs the Architecture Review Board with the Decision Steward.

Key responsibilities:

  • Intent: no Intent is validated unless a Capability Owner points to the real system that carries it.
  • Decision: guarantees a human validation step for every irreversible action of an n8n workflow.
  • Learning: sets the maximum decision validation delay to avoid stalled decisions.

Skills: Fundamentals of enterprise architecture modeling, reading complex technical dependencies, prior experience governing architecture decisions.

Access: Experience as an enterprise architect or IT domain lead, legitimacy already recognized internally to join strategic framing workshops.

For: Enterprise architects, senior solution architects

02

Decision Steward

Owns the decision process

Guarantor of the Living ADR lifecycle, runs reviews of drifting decisions and co-leads the Architecture Review Board with the Architecture Owner.

Key responsibilities:

  • Knowledge/Decision: qualifies each piece of data under the Declared, Observed, Inferred, Validated taxonomy.
  • Automation: ensures every n8n workflow execution is logged with a timestamp.
  • Human-in-the-loop: identifies a human validator for every critical decision.

Skills: Fundamentals of enterprise architecture modeling, methodological rigor combined with recognized authority over architecture arbitrations.

Access: Generally emerges in Phase 3, once the first decision-traceability mechanisms are put in place — the hardest role to map onto an existing position.

For: IT governance leads, architecture project managers

03

AI Control Officer

Oversees the AI Control Plane

Responsible for the AI Control Plane and for AI agent routing, security and cost policy. Governs the model behind each agent, distinct from the capability it serves.

Key responsibilities:

  • Automation: ensures no AI agent is directly connected to unfiltered sensitive data.
  • Knowledge: ensures every Inferred datum states the agent and model that produced it.
  • Human-in-the-loop: sets the confidence threshold below which human validation is mandatory.

Skills: Understanding of AI agent architectures, retrieval-augmented generation, and AI security concerns (prompt injection, data poisoning, model drift) — a rare profile in the market.

Access: Only emerges in Phase 3 in principle, once the project addresses the AI exoskeleton design; an early appointment risks confining the role to a decorative function.

For: CISOs, AI governance leads, MLOps/AIOps leads

04

Capability Owner

Owns a business or technical capability

Named owner of a critical business capability. Their value lies in operational knowledge of the business domain, not deep architecture expertise.

Key responsibilities:

  • Automation: carries a unique, documented identifier for every n8n workflow in their scope.
  • Knowledge: identifies the system source of every datum mobilized by their capability.
  • Human-in-the-loop: gives the human validator the context needed to arbitrate, not just the result.

Skills: Deep knowledge of their business domain and its main system dependencies; no deep architecture expertise required, acquired progressively.

Access: Emerges as early as Phase 2, when the initial Capability Map is built — several Capability Owners typically coexist, one per priority capability domain.

For: Product owners, business domain leads

05

Compliance Liaison

Links architecture and compliance

Liaison between Continuous Governance and regulatory obligations — NIS2, EU AI Act, GDPR.

Key responsibilities:

  • Automation/Security: ensures an audit log retains every automated action.
  • Learning/POC: documents observed risks — not just benefits — before any Go/No-Go decision.
  • AI agents: checks that the TEAF Agent Interface's Permissions and Limits cover applicable regulatory requirements.

Skills: Command of the regulatory frameworks applicable to the organization's sector, offset by close collaboration with the Architecture Owner where architecture expertise is lacking.

Access: Benefits from being identified as early as project launch, especially in heavily regulated sectors — late involvement exposes the project to costly rework.

For: DPOs, compliance leads, IT counsel

06

Executive Sponsor

Link between the TEAF Loop and the executive board

Carries the executive legitimacy of the TEAF program to the board or steering committee: arbitrates priorities across capability domains, unlocks resources, and shields the loop from short-term pressure that would pull it back to governance-by-cycle.

Skills: Recognized executive-level authority, ability to translate architecture concerns into enterprise governance concerns for the board.

Access: A role extending the certification program beyond the five roles fixed by Book II — job description still being drafted, like the rest of the program.

Role extending the program — job description in preparation

For: Board members, program sponsors, CIOs

07

TEAF Implementation Consultant

Deploys TEAF at a client organization

Leads TEAF deployment on behalf of a client organization: frames the four deployment phases, runs workshops, and transfers skills to internal roles once the engagement ends.

Skills: Command of the TEAF collection and TEAF Light, experience leading enterprise architecture consulting engagements.

Access: A role extending the program on the provider side rather than the client side — job description still being drafted.

Role extending the program — job description in preparation

For: Independent consultants, partner firms

Where to start

TEAF Practitioner — the generalist certification

Before specializing in a role, a common foundation: the eight-component loop, the ten principles, the artifacts (Living ADR, Knowledge Backbone, Capability Map) and the maturity pyramid. This is the baseline consultants and architects need to operate on a TEAF engagement, whatever role they take on next.

Access conditions

A technical background is required, not an exam open to all

Access to each certification will be conditioned on an adequate technical background for the target role — the "Access" detail on each card above gives its prerequisite, drawn from the reference job descriptions in the TEAF Light repository. A symbolic registration fee will be requested once the program opens, to cover organizational costs — no amount is set at this stage.

Stated plainly: a certification program isn't, today, the most decisive factor for TEAF's adoption. It remains necessary for two reasons — giving a verifiable framework to the ongoing scientific validation phase, and establishing the project's credibility with organizations considering a public association with it.

Current status

A program in preparation, not yet open

The content of each certification (competency framework, assessment format, terms) is under construction, in step with the collection's V2 and the field feedback gathered from the first organizations. No opening date is announced yet — no promise until the program is actually ready to deliver on it.