Preamble
Why this document exists
A new category of enterprise risk is forming faster than the governance vocabulary to describe it.
Autonomous AI agents are being deployed into production environments today. They act. They access data. They call tools. They hand work to other agents. They make decisions that carry organizational consequences. And in most enterprises deploying them, no one has defined what accountability looks like for any of it.
This is not a technology problem. The infrastructure layer is maturing rapidly. Agent identity systems, runtime policy enforcement, memory governance tooling, activity logging. The harness that captures what an agent does is being built, funded, and deployed. The technology will arrive.
The accountability gap is not in the harness. It is in what the harness is required to prove.
A log that records every action an agent took does not constitute accountability. Accountability requires that every action be traceable to a human authorization event, that every permission be bounded to a specific task, that every handoff carry the authorization chain forward, and that the whole of it be reconstructible by the organization without dependence on a vendor. A log that satisfies none of those conditions is observation. It is not governance.
This document defines the minimum conditions under which an enterprise can claim its agentic AI deployment is accountable by design.
It is not a technical specification. It does not prescribe tooling, architecture, or vendor selection. It is vendor-neutral by design, because the moment an accountability standard is authored by someone selling the infrastructure it covers, it is no longer an accountability standard.
It is not a compliance framework. It does not map to a regulatory requirement or create one. It is a governance standard: a definition of what sufficient looks like, authored independently, so that enterprises, auditors, regulators, and practitioners have a common reference point when they ask whether an agentic deployment closes the accountability gap or merely generates data.
Version 0.1 established the seven foundational accountability conditions. Version 0.2 adds an eighth condition addressing model identity verification. The Baseline will continue to evolve as agentic AI deployments mature and as practitioners operating inside the gap contribute to the methodology.
The Vordan Accountability Framework principle applies throughout: accountability must be built in before deployment, not retrofitted after failure. A system that requires a post-mortem to discover its accountability gaps was not built with accountability in mind.
Section 1
Scope and Applicability
The Baseline applies to any production deployment of one or more autonomous AI agents that take actions, access data, use tools, or transfer work to other agents on behalf of an organization, with or without human oversight at the action level.
The minimum conditions that trigger Baseline applicability are autonomous action, tool use, memory access, or handoff capability. A system that only suggests actions for a human to approve is a copilot. The Baseline does not govern copilots. A system that performs actions is an agent. The Baseline governs agents.
The Baseline applies regardless of the infrastructure vendor, the agent framework, or the underlying model. It is not contingent on organizational size, industry, or regulatory context. Any organization deploying agents that act on its behalf operates within the accountability conditions this document defines.
Section 2
The Eight Accountability Conditions
Each condition translates an infrastructure question the harness answers into a governance requirement the organization must satisfy. The harness question establishes what the technology can capture. The accountability condition establishes what the organization must require.
Conditions 2.1 through 2.7 govern how an agent acts. Condition 2.8 governs what the agent is. That distinction is architectural. An agent that cannot verify its own identity has an accountability gap that precedes every other condition.
2.1
Authorization Provenance
The harness question
Is there a record of when and how this agent was deployed?
The accountability condition
Every action taken by an autonomous agent must be traceable to a human authorization event that preceded it. Deployment provenance is not authorization provenance. The existence of an agent in a production environment does not constitute organizational authorization for any specific action it takes. Authorization provenance requires a documented human decision, identifiable by role, timestamp, and scope, that explicitly sanctions the agent to act within defined boundaries on a defined task.
The gap
When an agent acts under standing permissions rather than task-specific authorization, the accountability chain begins with the agent, not with a human decision. That is not accountability by design. It is accountability abdicated at the point of deployment.
Authorization is not a configuration. It is a decision. The audit trail must show the decision, not just the configuration that followed from it.
2.2
Scope Integrity
The harness question
What permissions does this agent have?
The accountability condition
Agent permissions must be narrow, temporary, and revocable. Narrow means bounded to the specific task for which authorization was granted, with no ambient access to systems, data, or tools outside that scope. Temporary means permissions expire when the task ends, not when the agent is decommissioned. Revocable means a human with appropriate authority can terminate permissions immediately, without requiring a change to the agent's underlying configuration.
The gap
Persistent broad permissions that survive task completion are a scope integrity failure. An agent that retains access to systems it no longer needs for any authorized purpose is operating outside its accountability boundary, regardless of whether it acts on that access.
The accountability condition is not whether the agent used its excess permissions. It is whether excess permissions existed. The gap is structural, not behavioral.
2.3
Memory Governance
The harness question
What can this agent read from and write to memory?
The accountability condition
Every memory access, read or write, must be attributable to an authorized purpose, connected to an accountable owner, and auditable after the fact. It is not sufficient for the harness to log that a memory access occurred. The log must be interpretable: what was accessed, in the context of which task, under whose authorization, and for what stated purpose. Write operations require a higher evidence standard: what was written must be attributable to a human-authorized decision, not an autonomous inference.
The gap
Memory that accumulates across sessions without an owner, a purpose boundary, or an expiration condition is ungoverned memory. An agent with access to ungoverned memory is an agent operating partially outside the accountability architecture, regardless of how well the rest of the deployment is governed.
Memory is not a neutral resource. It is a data asset with governance obligations. The accountability condition applies to what the agent remembers, not just what it does.
2.4
Handoff Traceability
The harness question
Which agents did this agent transfer work to?
The accountability condition
Every transfer of work between agents must carry the authorization chain forward intact. A handoff that transfers a task without transferring the authorization context that sanctioned the task is an accountability gap, regardless of whether the technical handoff succeeded. The receiving agent must be able to answer, from the handoff record alone, who originally authorized the work, what scope that authorization covered, and whether the receiving agent's actions fall within that scope.
The gap
Authorization chains that terminate at the first handoff create accountability voids in every downstream agent action. The organizational liability for what downstream agents do does not terminate at the handoff. The accountability architecture must extend to wherever the work goes.
A handoff is not a transfer of liability. It is a transfer of task with continuity of accountability. The chain must survive the handoff or the handoff breaks the governance architecture.
2.5
Prompt Integrity
The harness question
What data entered this agent's context?
The accountability condition
What enters an agent's context must be controlled, auditable, and protected against unauthorized manipulation. Prompt injection, the introduction of instructions through data channels not intended to carry instructions, is an accountability failure before it is a security failure. It breaks the authorization chain by causing an agent to act under instructions that were never authorized by any human decision. Context contamination from unverified external sources carries the same accountability consequence: the agent acted, but not under any authorization the organization can identify or own.
The gap
An agent whose behavior can be altered by data it retrieves from external sources, other agents, or user-supplied content, without a control layer that validates that content against authorized instruction sources, is an agent whose actions cannot be fully attributed to organizational authorization. The accountability chain has an exploitable break at the context boundary.
Authorization governs instructions, not just permissions. An agent that can be instructed through its data inputs has an authorization boundary that the harness alone cannot secure. The accountability condition requires that the instruction surface be governed, not just logged.
2.6
Decision Auditability
The harness question
Is there a log of what actions the agent took?
The accountability condition
Actions above a defined sensitivity threshold must have an approval record connected to an accountable human decision point. The sensitivity threshold must be defined before deployment, not determined retroactively. An automated approval, a rule that triggers without human review, does not satisfy this condition for sensitive actions. The audit trail must show a human decision, identifiable by role and timestamp, that authorized the specific action or class of action before it was taken.
The gap
A log that records what an agent did is not an approval record. Recording an action after the fact proves the action occurred. It does not prove it was authorized. For sensitive actions, the accountability condition requires prospective authorization, not retrospective documentation.
The audit trail must answer two distinct questions: what did the agent do, and who decided it should. A trail that answers only the first question is an observation record. A trail that answers both is an accountability record.
2.7
Forensic Reconstructibility
The harness question
Do we have logs sufficient to investigate an incident?
The accountability condition
When something goes wrong, the organization must be able to reconstruct who did what, under whose authority, on what data, and why, from its own audit trail, without requiring access to vendor infrastructure, vendor personnel, or vendor-held logs. Forensic dependence on the vendor is an accountability gap. If the organization cannot independently reconstruct the sequence of events, it cannot independently establish accountability. It cannot answer to a regulator, a board, or an affected party without the vendor's cooperation, cooperation that may not be available, timely, or unconflicted.
The gap
Logs held exclusively by the infrastructure vendor, logs that require vendor tooling to interpret, and logs that are inaccessible without an active vendor relationship are not organizational audit trails. They are vendor-held records that the organization may be permitted to access under current contract terms. The accountability condition requires that the organization own the forensic record, not lease access to it.
Accountability cannot be outsourced. The organization that deployed the agent bears the accountability for what it did. That accountability requires the independent capacity to reconstruct the agent's actions. A governance architecture that depends on vendor cooperation to establish what happened is not accountable by design.
2.8
Model Substrate Integrity
The harness question
Is there a record of which model was deployed?
The accountability condition
An accountable agentic deployment must be able to verify, through a mechanism independent of the deploying party's assertion, that the model executing its instructions is the model it was authorized to deploy. Namespace, documentation, and community attestation do not satisfy this condition. Verification must be technically grounded: the deployed model must be capable of producing evidence of its identity that cannot be forged by a model with different parameters. Where no independent verification mechanism exists, the absence of verification is itself a condition finding. An organization that cannot verify the identity of the model its agents are running cannot satisfy Authorization Provenance for any action those agents take.
The gap
Model distribution infrastructure does not currently provide technical model identity verification. Weights retrieved from public repositories may have been substituted, modified, or backdoored between publication and download with no platform-level mechanism to detect the change. An agentic deployment that retrieves and executes weights without independent identity verification has delegated a foundational accountability decision to the distribution platform's social controls. Social controls are not a governance architecture.
Authorization Provenance requires knowing who authorized what. It cannot be satisfied if the identity of the model taking action is unverified. Model Substrate Integrity is the precondition for every other condition in this Baseline.
Section 3
Evidence Standards
Each evidence standard is organized into three tiers: what must exist, what must be demonstrable on demand, and what must be independently verifiable. Any technical implementation that produces the required evidence satisfies the standard. Any implementation that does not, regardless of how sophisticated the underlying infrastructure, does not.
3.1 Authorization Provenance
Must exist
A human authorization record for each agent deployment, containing the authorizing role, the timestamp of authorization, the scope of authorized actions, the data sources the agent is permitted to access, and the conditions under which authorization expires or must be renewed.
Must be demonstrable on demand
For any agent action in the audit trail, the organization must be able to produce the authorization record that preceded and sanctioned that action. The connection between action and authorization must be traceable without vendor assistance.
Must be independently verifiable
The authorization record must be stored in a system the organization controls, not exclusively in vendor infrastructure. It must be immutable after creation. Any modification to an authorization record must itself generate an auditable event with its own authorization provenance.
3.2 Scope Integrity
Must exist
A permission manifest for each agent deployment documenting the specific systems, data sources, and tools the agent is permitted to access, the conditions under which each permission is active, and the expiration condition tied to task completion.
Must be demonstrable on demand
For any point in time during an agent's operational period, the organization must be able to produce a complete picture of what permissions were active, what had expired, and what had been revoked. The organization must be able to demonstrate that no permissions persisted beyond their authorized scope.
Must be independently verifiable
Permission state changes must be logged as discrete auditable events. The log must show when permissions were granted, when they expired or were revoked, and whether any actions were taken during periods when permissions should not have been active.
3.3 Memory Governance
Must exist
A memory access log that records every read and write operation performed by the agent, the task context in which each operation occurred, the authorization under which it was performed, and the owner responsible for the data accessed or created.
Must be demonstrable on demand
For any memory access in the log, the organization must be able to identify the purpose that justified it and the human authorization that sanctioned the task it served. Write operations must additionally be traceable to the specific decision or output that generated them.
Must be independently verifiable
Memory that persists across sessions must have a documented owner, a documented purpose, and a documented expiration or review condition. Memory without an owner is ungoverned memory. Its existence in the audit trail is a gap finding, not a clean record.
3.4 Handoff Traceability
Must exist
A handoff record for every transfer of work between agents, containing the originating agent identifier, the receiving agent identifier, the task being transferred, the authorization context being carried forward, and the timestamp of transfer.
Must be demonstrable on demand
For any action taken by any agent in a multi-agent workflow, the organization must be able to trace that action back to the original human authorization event through an unbroken chain of handoff records. A chain with a missing link is an accountability void regardless of how well the surrounding links are documented.
Must be independently verifiable
Handoff records must be stored in a way that neither the originating nor the receiving agent can modify after the fact. The integrity of the handoff record must be verifiable independently of the agents involved in the transfer.
3.5 Prompt Integrity
Must exist
A context log for each agent session that records what entered the agent's context, the source of each input, whether each input was from an authorized instruction channel or a data channel, and whether any input was flagged or filtered by a prompt integrity control.
Must be demonstrable on demand
For any agent action, the organization must be able to produce the full context that was present when the action was taken and identify whether any element of that context originated from an unauthorized or unverified source.
Must be independently verifiable
The context log must be produced at the time of the session, not reconstructed afterward. Retroactive reconstruction of what entered an agent's context does not satisfy this evidence standard. The log must be contemporaneous.
3.6 Decision Auditability
Must exist
A sensitivity classification for agent action types, defined before deployment, that specifies which actions require prospective human authorization rather than automated execution. For each action above the sensitivity threshold, an approval record containing the approving role, the timestamp of approval, and the specific action or action class approved.
Must be demonstrable on demand
For any sensitive action in the audit trail, the organization must be able to produce the approval record that preceded it. The time gap between approval and action must be explainable. Approvals that postdate the actions they purport to authorize do not satisfy this evidence standard.
Must be independently verifiable
The sensitivity classification must be a governing document, versioned and dated, that predates the deployment it governs. Post-hoc sensitivity classifications applied to actions already taken do not constitute prospective authorization.
3.7 Forensic Reconstructibility
Must exist
An organizational audit trail, stored in infrastructure the organization controls, that contains sufficient information to reconstruct the complete sequence of agent actions, the authorization state at each point in the sequence, the data accessed or modified, and the decision points where human authorization was required and obtained.
Must be demonstrable on demand
The organization must be able to conduct a full forensic reconstruction of any agent session using only its own audit trail, without accessing vendor infrastructure, contacting vendor personnel, or invoking any vendor-provided forensic tooling. If the reconstruction requires vendor cooperation at any point, that dependency is a gap finding.
Must be independently verifiable
The audit trail must be tamper-evident. Any modification to the trail after the fact must itself generate an auditable event. Log completeness must be verifiable: gaps in the timeline are findings, not unknowns.
3.8 Model Substrate Integrity
Must exist
A model identity record for each agentic deployment documenting the specific model authorized for use, the version or checkpoint identifier, the source from which weights were retrieved, the date of retrieval, and the verification method applied to confirm the retrieved weights correspond to the authorized model.
Must be demonstrable on demand
The organization must be able to demonstrate, for any point in the deployment's operational period, that the model executing instructions was the model authorized to do so. Where the underlying model has not changed, the model identity record serves as evidence. Where verification tooling exists, verification logs must be available. The organization must be able to distinguish between an unverified assertion and a verified fact regarding model identity.
Must be independently verifiable
Verification cannot rest solely on the distribution platform's namespace or documentation. Where a cryptographic or technically grounded verification mechanism is available and applicable to the deployed model, its use is required. Where no such mechanism currently exists for the model in question, the organization must document that fact explicitly as a known gap and assess the residual risk of unverified model identity against its accountability posture. Stating that no verification mechanism exists is not a gap finding. Failing to assess and document that absence is.
Section 4
Accountability Gap Classification
When an accountability condition is not met, the nature of the gap determines the remediation path. Vordan classifies accountability gaps into three types. Every gap finding produced by a Baseline assessment will carry one of these classifications.
Type 1
Structural Gap
The accountability condition cannot be satisfied by the current architecture, regardless of process changes or ownership assignments. The limitation is in how the system was built. No policy document, no governance committee, and no additional logging will close a structural gap. The architecture must change.
Type 2
Procedural Gap
The technical capability to satisfy the accountability condition is present but no process, ownership structure, or governance mechanism activates it. The architecture can support accountability. The organization has not built the governance layer that makes it function.
Type 3
Technical Gap
The architecture supports the accountability condition and a governance process has been designed to activate it, but a specific technical implementation failure prevents the condition from being fully satisfied. The intent is present. The execution has a defect.
Each gap type carries a distinct remediation path and risk posture. Structural gaps require architectural intervention before any other remediation is meaningful. Procedural gaps are closeable without architectural change through ownership assignment, process design, and governance documentation. Technical gaps are the most straightforward to remediate: they require a specific engineering fix to bring the implementation into alignment with the standard.
| Severity | Condition |
|---|---|
| Critical | Structural gap in Authorization Provenance, Handoff Traceability, Forensic Reconstructibility, or Model Substrate Integrity. The organization cannot establish accountability for agent actions in the affected domain under any circumstances. |
| High | Structural gap in any remaining condition, or procedural gap in Authorization Provenance, Handoff Traceability, or Forensic Reconstructibility. |
| Medium | Procedural gap in any remaining condition, or technical gap in Authorization Provenance, Handoff Traceability, or Forensic Reconstructibility. |
| Low | Technical gap in any remaining condition. The architecture is correct, the governance intent is correct, and the defect is specific and remediable. |
Section 5
Relationship to Existing Frameworks
The Baseline is complementary to existing governance frameworks and derivative of none. Existing frameworks were not designed for the specific accountability conditions that arise when autonomous agents act on behalf of organizations. The Baseline does not replace them. It extends into territory they have not covered.
NIST AI Risk Management Framework (AI RMF 1.0)
Where it aligns
The Govern and Map functions create space for the accountability architecture the Baseline requires. The AI RMF's emphasis on human oversight, transparency, and explainability maps directly to the Baseline's conditions on Decision Auditability and Forensic Reconstructibility.
Where the Baseline extends beyond it
The AI RMF does not address agentic deployments specifically. Its accountability constructs were developed for AI systems that operate under continuous human oversight, not for autonomous agents that act, hand off work, and accumulate memory across sessions with minimal human intervention at the action level.
Practitioner guidance
Treat the Baseline as an agentic extension of the Govern and Map functions. The seven accountability conditions provide the specific requirements that the AI RMF's principles imply but do not specify for autonomous agent deployments.
ISO/IEC 42001: Artificial Intelligence Management System
Where it aligns
ISO 42001 requires organizations to determine the context of their AI systems, establish roles and responsibilities, and maintain documented information sufficient to demonstrate conformance. These requirements create an organizational infrastructure that is necessary for, though not sufficient to satisfy, the Baseline's accountability conditions.
Where the Baseline extends beyond it
An organization can achieve ISO 42001 conformance while deploying agentic AI systems that satisfy none of the Baseline's seven conditions, because ISO 42001 does not require those conditions to be met. The distinction is between having a management system and having an accountability architecture.
Practitioner guidance
Organizations pursuing ISO 42001 certification should treat the Baseline as the agentic AI addendum to their AI management system documentation. Organizations that satisfy the Baseline's evidence standards for agentic deployments will have substantially completed the documented information requirements for those deployments under ISO 42001.
NIST Cybersecurity Framework 2.0 (CSF 2.0)
Where it aligns
The Govern function's emphasis on organizational context and risk management strategy provides a direct foundation for several Baseline conditions. The Identify function's asset management category covers the agent inventory that Authorization Provenance requires. The Detect and Respond functions cover the incident response and forensic reconstruction requirements that Forensic Reconstructibility demands.
Where the Baseline extends beyond it
The CSF 2.0 does not address the specific accountability failures unique to autonomous agents: the authorization chain breaking at handoff, ungoverned memory accumulating across sessions, prompt injection breaking the instruction boundary, or forensic dependence on vendor infrastructure.
Practitioner guidance
Map the Baseline's eight conditions to CSF 2.0 functions as follows: Authorization Provenance and Scope Integrity map to Govern and Identify. Memory Governance and Prompt Integrity map to Protect and Detect. Handoff Traceability and Decision Auditability map to Govern and Respond. Forensic Reconstructibility maps to Recover. Model Substrate Integrity maps to Identify and Govern as a supply chain integrity requirement.
ISACA COBIT 2019
Where it aligns
COBIT's governance domain addresses accountability assignment, stakeholder needs, and governance system design in ways that directly support the Baseline's requirements. Its management objectives around risk management, audit, and compliance provide organizational structures that the Baseline's evidence standards assume are present.
Where the Baseline extends beyond it
COBIT was designed for IT governance broadly and predates the emergence of agentic AI as a distinct governance challenge. Organizations using COBIT as their governance reference will find that the framework provides the organizational scaffolding for accountability but does not specify what accountability requires in the agentic context.
Practitioner guidance
Treat the Baseline as a domain-specific governance standard that operates within the COBIT governance architecture. The Baseline's accountability conditions represent the specific governance objectives that COBIT's framework structures should be directed toward for agentic AI deployments.
Every framework referenced in this section was developed before autonomous AI agents became a production reality in enterprise environments. Existing frameworks provide the organizational context in which the Baseline operates. They do not provide the accountability conditions the Baseline defines. Both are necessary. Neither is sufficient without the other.
Section 6
Versioning and Governance
The Agentic Accountability Baseline is a living standard. Version 0.2 adds Condition 2.8 (Model Substrate Integrity) in response to documented accountability failures in AI model distribution infrastructure. It will continue to evolve as agentic AI deployments mature and as practitioners contribute observations from the field.
6.0 Version History
Version 0.1, May 2026. Initial publication. Established the seven foundational accountability conditions (2.1 Authorization Provenance through 2.7 Forensic Reconstructibility), evidence standards, gap classification taxonomy, and framework alignment mappings.
Version 0.2, June 2026. Added Condition 2.8: Model Substrate Integrity. This condition was introduced in response to the documented gap in AI model distribution infrastructure, specifically the absence of technical model identity verification controls at platforms serving as primary distribution channels for open-weight AI models, and the emergence of cryptographic verification primitives capable of addressing that gap. The addition was preceded by Vordan Gap Alert Seventeen (June 5, 2026). The section heading in Section 2 has been updated from Seven to Eight Accountability Conditions. Evidence Standard 3.8 and Checklist Item 2.8 have been added. The severity classification table has been updated to reflect the Critical status of structural gaps in Model Substrate Integrity.
6.1 Version Structure
The Baseline uses a two-part version number: major version and minor version, separated by a decimal point. A minor version increment reflects refinements to existing conditions, clarifications to evidence standards, additions to the gap classification taxonomy, or updates to framework alignment mappings. A major version increment reflects a material change to the accountability conditions themselves and will be preceded by a public comment period of no less than sixty days.
Version 1.0 will be published when the methodology has been validated through field assessments and the conditions have demonstrated sufficient stability to serve as a durable enterprise reference standard.
6.2 Comment and Contribution Process
Practitioners, researchers, and organizations may submit observations, challenges, and proposed refinements through the Vordan editorial channel at hello@vordan.co with the subject line Baseline Feedback. Submissions should reference the specific section, condition, or evidence standard being addressed and provide a practitioner rationale for the proposed change.
Vordan does not accept feedback from infrastructure vendors regarding the conditions that govern the infrastructure they sell. The independence of the standard from vendor interest is a structural property, not a policy preference. It will be maintained across all versions.
6.3 Assessment Record Governance
Organizations that conduct Baseline assessments should maintain their assessment records as governed documents subject to the same retention and integrity requirements as other audit artifacts. Assessment records should contain the version of the Baseline against which the assessment was conducted, the date of the assessment, the scope of the agentic deployments assessed, the gap findings by condition and type, the severity classifications assigned, and the remediation commitments made in response to each finding.
Assessment records are governance artifacts. Their existence demonstrates accountability by design. Their absence, in an environment where the standard is publicly available and the assessment methodology is documented, is itself a posture finding.
6.4 Relationship to the Gap Score Instrument
The Gap Score is Vordan's assessment instrument for measuring an organization's accountability posture against the Baseline. The Gap Score agentic module maps directly to the eight conditions in Section 2 and the evidence standards in Section 3. The Gap Score instrument will be published separately as a companion document to this Baseline.
6.5 Publication and Distribution
The Baseline is published by Vordan at vordan.co and distributed through the Vordan publication at reports.vordan.co. It is freely available for reference, citation, and organizational use. Organizations may incorporate the Baseline's conditions and evidence standards into their internal governance documentation provided they cite Vordan as the source and reference the specific version they are using.
Citation format: Vordan Agentic Accountability Baseline, Version 0.2, June 2026. vordan.co/baseline
Appendix A
Glossary
Terms used in this document that carry specific meanings within the Vordan accountability framework.
Appendix B
Baseline Assessment Checklist
A condensed reference for practitioners conducting an initial accountability posture review. A negative response to any item indicates a gap finding requiring classification and remediation per Section 4.
Citation
Vordan Agentic Accountability Baseline, Version 0.2, June 2026. vordan.co/baseline
Published by Vordan. Feedback: hello@vordan.co with subject line "Baseline Feedback". For assessment inquiries: hello@vordan.co