AIFC-063: Auditability

Status: Draft 0.1 Standard: AI-First Community Standard Short name: AIFC Builds on:

• AIFC-000 Manifesto for AI-First Communities
• AIFC-001 Core Concepts
• AIFC-010 Knowledge Structure
• AIFC-011 Operational DNA
• AIFC-012 Metadata and Markdown
• AIFC-020 Human-Managed AI
• AIFC-021 AI as External Expert Capacity
• AIFC-022 AI-NDA Boundary
• AIFC-023 AI as Team Member
• AIFC-030 AI Capacity Planning
• AIFC-031 AI Autonomy and Intensity
• AIFC-032 AI Operating Modes
• AIFC-033 AI Budget and Cost Control
• AIFC-034 AI Lock-in and Exit Strategy
• AIFC-050 Community Interface
• AIFC-060 Knowledge Security
• AIFC-061 Access Control
• AIFC-062 Agent Permissions

Purpose of this document: Define Auditability as the community’s ability to trace, explain, and verify meaningful actions by people, AI agents, systems, vendors, and communities over the knowledge base, Source of Truth, Operational DNA, AI workflows, decisions, access, exports, and changes. Auditability protects trust, responsibility, security, governance, and learning capability.

1. Purpose of this document

This document defines Auditability.

An AIFC community works with people, AI agents, systems, tools, vendors, and a knowledge base.

These actors may:

• read knowledge artefacts,
• change the Source of Truth,
• create proposals,
• approve decisions,
• process data with AI,
• export know-how,
• change classification,
• change agent permissions,
• run tools,
• communicate externally,
• create derived knowledge,
• or work with Operational DNA.

Auditability means the community can later determine:

• who or what acted,
• what exactly was done,
• when it happened,
• why it happened,
• under which permission,
• in which operating mode,
• with which data,
• under which skill or rule,
• who approved it,
• what the result was,
• and what impact it had.

Without auditability, an AI-first community becomes an opaque system.

2. Core principle

The core principle of this document is:

Critical actions must be traceable, explainable and reviewable.

AIFC states:

No invisible authority.
No untraceable AI action.
No critical change without evidence.

Auditability is not bureaucracy.

It protects trust and the community’s ability to understand its own operation.

3. Definition

Auditability is the ability to record, trace, explain, and verify meaningful actions, decisions, access events, changes, and AI interactions in a community.

Auditability applies to:

• people actions,
• AI agent actions,
• system actions,
• vendor actions,
• access grants,
• access revocations,
• Source of Truth changes,
• classification changes,
• AI processing,
• AI-generated outputs,
• approvals,
• decisions,
• exports,
• external sharing,
• budget exceptions,
• operating mode changes,
• AI-NDA Boundary changes,
• agent permissions changes,
• incidents,
• fallback activations,
• recovery actions.

Minimum requirement

Meaningful actions over Restricted knowledge, Operational DNA, AI governance, Source of Truth, or decisions must be auditable.

4. Why Auditability matters

Auditability matters because without it the community does not know what actually happened.

Without auditability, the community cannot reliably answer:

• Who changed the decision?
• Why did the AI agent write this proposal?
• Which model processed Restricted data?
• Who approved vendor access?
• When was the export created?
• How did Operational DNA enter a public output?
• Why was autonomy level increased?
• Who disabled fallback?
• Where did AI dependency appear?
• Which know-how was used for an AI output?
• Which skill did the agent use?
• Who approved the budget exception?

Auditability enables:

• accountability,
• incident response,
• learning,
• compliance,
• trust,
• security,
• rollback,
• root cause analysis,
• vendor management,
• AI governance,
• exit strategy.

Minimum requirement

An AIFC community must understand auditability as a foundation of trustworthy AI-first operation.

5. Auditability vs logging

Logging and auditability are not the same.

Logging means the system records something.

Auditability means the records are usable for understanding and verifying meaningful actions.

Weak log:

Action executed successfully.

Better audit record:

Knowledge Maintenance Agent created draft change proposal CP-123 from observed signal OS-456 using approved internal documents D-12 and D-18. No restricted data used. Owner review required before write-back to active Source of Truth.

Auditability requires meaning, context, and traceability.

Minimum requirement

Audit records of critical actions must be understandable and usable for review, not merely technically present.

6. What must be auditable

AIFC recommends auditing these areas according to risk:

access
AI processing
agent actions
Source of Truth changes
approvals
decisions
exports
classification changes
AI-NDA Boundary changes
agent permissions changes
operating mode changes
budget exceptions
incidents
fallback activations
Operational DNA access

Not every small action needs the same audit level.

Critical actions must be traceable.

Minimum requirement

The community must define which action types require audit according to classification and impact.

7. Audit subject

The audit subject is the actor that performed the action.

It may be:

• human,
• AI agent,
• system,
• integration,
• vendor,
• external expert,
• service account,
• another community,
• automated workflow.

Audit must distinguish whether the action was performed by a person, AI, or system.

If AI acted under human delegation, the audit must also show the owner or approver.

Minimum requirement

A critical audit record must identify the actor and actor type.

8. Audit action

The audit action describes what happened.

Examples:

• read,
• search,
• retrieve,
• summarize,
• classify,
• propose,
• edit,
• approve,
• reject,
• publish,
• export,
• share,
• delete,
• declassify,
• process with AI,
• run agent,
• call tool,
• change permissions,
• activate operating mode,
• revoke access.

The action must be specific enough.

Minimum requirement

A critical audit record must state the action type.

9. Audit object

The audit object is the artefact or system affected by the action.

It may be:

• knowledge artefact,
• Source of Truth file,
• Decision Record,
• AI skill,
• human skill,
• agent permissions record,
• AI-NDA Boundary,
• customer data,
• Operational DNA artefact,
• export package,
• prompt,
• output,
• workflow,
• interface,
• access policy,
• budget plan.

Minimum requirement

A critical audit record must identify the affected object or object scope.

10. Audit purpose

Audit purpose explains why the action was performed.

Examples:

• review,
• migration,
• support investigation,
• security incident,
• AI retrospective,
• workflow conversion,
• vendor assessment,
• mission mode,
• maintenance,
• customer request,
• compliance audit.

Purpose matters because the same access may be legitimate in one context and illegitimate in another.

Minimum requirement

Access to Restricted knowledge, Operational DNA, AI processing, and export must have an auditable purpose.

11. Audit permission basis

Audit must show why the action was allowed.

Permission basis may be:

• role,
• access request,
• approval,
• AI-NDA Boundary,
• agent permissions,
• operating mode,
• emergency access,
• delegated authority,
• policy,
• contract,
• legal obligation.

Minimum requirement

A critical action must be traceable to a permission basis or approval.

12. Audit approval

For actions requiring approval, the audit must record:

• who approved,
• when,
• what was approved,
• what scope applied,
• what conditions applied,
• whether it was an exception,
• when approval expires,
• whether separation of duties was used.

Minimum requirement

Approval of critical actions must be auditable.

13. Audit data classification

Audit must record the classification of affected data or artefacts.

Example:

public
internal
restricted
operational_dna

If AI creates derived knowledge, the audit should record its classification or the need for classification.

Minimum requirement

Actions over Restricted knowledge or Operational DNA must audit data classification.

14. Audit AI processing

AI processing audit records the use of AI over knowledge artefacts.

It should include:

• which AI tool or model was used,
• who or what started processing,
• which data was used,
• what classification applied,
• what purpose applied,
• whether the AI-NDA Boundary was met,
• whether memory was allowed,
• whether training was allowed,
• what output was created,
• whether derived knowledge was created,
• who reviewed the output,
• whether the output was approved.

Minimum requirement

AI processing of non-public know-how must be auditable according to sensitivity.

15. Audit prompts and outputs

Critical AI workflows may require prompt and output audit.

This does not always mean storing the whole prompt and output forever.

The community must consider:

• sensitivity,
• retention,
• privacy,
• incident needs,
• reproducibility,
• vendor constraints,
• compliance,
• Source of Truth write-back.

Options:

• full prompt/output logging,
• redacted logging,
• metadata-only logging,
• hash/reference logging,
• secure audit vault,
• no logging with compensating controls.

Minimum requirement

Critical AI workflows must have a defined prompt/output audit policy.

16. Audit agent actions

Agent action audit records what an AI agent did.

It should include:

• agent identity,
• owner,
• action,
• tool used,
• input artefacts,
• output artefacts,
• permissions used,
• AI skill used,
• autonomy level,
• operating mode,
• approval status,
• cost,
• result,
• errors,
• escalations.

Minimum requirement

Autonomous or tool-using agents must have an audit trail appropriate to risk.

17. Audit Source of Truth changes

Source of Truth changes are critical.

Audit must show:

• what changed,
• who or what made the change,
• whether it was draft, proposal, or active content,
• who approved,
• why the change was made,
• which related Decision Record exists,
• whether it was AI-generated content,
• what classification applied,
• what the previous state was,
• how the change can be reverted.

Minimum requirement

Critical Source of Truth changes must have change history and rollback path.

18. Audit Decision Records

Decision Records must be auditable because they hold responsibility.

Audit must show:

• who decided,
• when,
• based on which inputs,
• what role AI had,
• what alternatives existed,
• which values were in tension,
• which risk was accepted,
• who was consulted,
• when the decision will be reviewed.

Minimum requirement

Critical decisions must have a Decision Record with auditable reasoning.

19. Audit access changes

Access changes must be auditable.

This includes:

• grant access,
• revoke access,
• change role,
• change AI access,
• allow export,
• allow AI processing,
• approve vendor access,
• approve emergency access,
• change agent permissions.

Minimum requirement

Changes to access for Restricted knowledge, Operational DNA, or AI processing must be auditable.

20. Audit exports

Export is a high-risk action.

Export audit must record:

• who exported,
• what was exported,
• when,
• why,
• to where,
• in what format,
• what classification applied,
• whether metadata was included,
• whether Operational DNA was included,
• whether it was encrypted,
• whether it was given to AI or a vendor,
• who approved the export,
• which retention rules apply.

Minimum requirement

Export of Restricted knowledge or Operational DNA must have an audit record.

21. Audit operating mode changes

AI Operating Mode changes may fundamentally change system behavior.

Audit must record:

• previous mode,
• new mode,
• scope,
• reason,
• trigger,
• owner,
• approval,
• budget impact,
• autonomy/intensity change,
• affected agents,
• start/end conditions.

Minimum requirement

Meaningful AI Operating Mode changes must be auditable.

22. Audit autonomy and permissions changes

Changing autonomy or agent permissions can increase risk.

Audit must record:

• what changed,
• why,
• who approved,
• what impact exists,
• which actions are newly allowed,
• which boundaries apply,
• when review will happen,
• what fallback exists.

Minimum requirement

Increasing AI autonomy or expanding agent permissions must be auditable.

23. Audit budget exceptions

AI budget exceptions may reveal cost growth or mission pressure.

Audit must record:

• who requested the exception,
• who approved it,
• why,
• how much it costs,
• for which scope,
• how long it applies,
• which operating mode is active,
• whether retrospective is needed.

Minimum requirement

Exceeding or granting an exception to a meaningful AI budget must be auditable.

24. Audit incidents

Knowledge security, AI governance, access, agent, boundary, or lock-in incidents must be auditable.

Audit must support:

• root cause analysis,
• containment,
• revocation,
• impact assessment,
• corrective actions,
• lessons learned,
• change proposals,
• retrospective.

Minimum requirement

Meaningful incidents must have an audit trail and post-incident review.

25. Audit fallback and recovery

Fallback and recovery actions must be auditable.

It is important to know:

• when fallback was activated,
• why,
• who decided,
• which scope was affected,
• what was disabled,
• what continued,
• when normal operation was restored,
• what the impact was.

Minimum requirement

Fallback activation for a critical workflow must be auditable.

26. Audit lineage

Lineage shows the origin of an output or artefact.

In AI-first knowledge, it is important to know:

• which inputs created the output,
• who or what created it,
• whether AI was used,
• which models/tools were used,
• who reviewed it,
• what was approved,
• how the output entered the Source of Truth.

Minimum requirement

Critical AI-generated artefacts must have basic lineage.

27. Audit retention

Audit logs must be retained appropriately.

Retention depends on:

• classification,
• legal requirements,
• incident risk,
• Operational DNA,
• AI-NDA Boundary,
• privacy,
• compliance,
• storage options,
• security risk of the logs themselves.

Audit logs may contain sensitive data.

They must be protected.

Minimum requirement

Audit logs of critical actions must have retention and protection rules.

28. Audit log security

An audit log is a sensitive artefact.

It may reveal:

• who has access,
• what is sensitive,
• which systems exist,
• which failures occurred,
• where weaknesses are,
• how agents work,
• which Operational DNA artefacts exist.

Audit logs must be protected against:

• unauthorized reading,
• change,
• deletion,
• export,
• AI use without boundary.

Minimum requirement

Audit logs must have access control, integrity protection, and classification appropriate to sensitivity.

29. Tamper resistance

Audit loses value if it can be easily changed.

Tamper resistance may include:

• immutable logs,
• append-only records,
• signed records,
• hash chain,
• protected storage,
• separation of duties,
• external audit trail,
• version history.

Not every community needs the same technical level.

Critical areas need integrity protection.

Minimum requirement

Audit records of critical actions must be protected against unauthorized change or deletion.

30. Human-readable audit

Audit must not be readable only by technicians.

Human-readable audit helps owners, reviewers, and governance roles understand:

• what happened,
• why,
• with what impact,
• what needs to happen next.

AI-first audit should be available through the Human Cockpit Layer in understandable views.

Minimum requirement

Responsible roles must have human-readable access to audit information for critical areas.

31. Agent-readable audit

Audit should also be usable by AI governance agents.

AI can help:

• detect patterns,
• warn about incidents,
• find permission drift,
• detect abnormal cost,
• find repeated access exceptions,
• detect unreviewed AI outputs,
• prepare retrospective inputs.

AI access to audit logs must respect classification and boundary.

Minimum requirement

AI access to audit logs must be explicitly governed and limited by sensitivity.

32. Software-verifiable audit

Some audit requirements must be software-verifiable.

Examples:

• every Operational DNA artefact has an owner,
• every AI agent has a permissions record,
• every export of Restricted content has approval,
• every active Decision Record has an approver,
• no AI-generated draft is marked active without review,
• every critical workflow has fallback.

Minimum requirement

Repeatable critical audit checks should become validation rules when practical.

33. Audit and AI Retrospective

Audit is an input to AI Retrospective.

It helps answer:

• where AI helped,
• where waste appeared,
• where dependency grew,
• where rejection rate was high,
• where an agent exceeded scope,
• where review was missing,
• where operating mode changed,
• where incidents appeared.

Minimum requirement

AI Retrospective must have access to relevant audit inputs according to scope and sensitivity.

34. Audit and Compliance

Auditability supports compliance, but is not only compliance.

Compliance asks:

Did we meet the requirement?

AIFC auditability also asks:

Do we understand what happened?
Can we learn from it?
Can we explain it?
Can we fix it?

Minimum requirement

Compliance audit should be complemented by learning and governance audit in critical AI-first areas.

35. Audit and accountability

Auditability supports accountability.

But audit should not be used first as blame-seeking.

It should enable the community to:

• understand the system,
• recognize weakness,
• improve rules,
• improve skills,
• correct access,
• adjust boundaries,
• strengthen capability,
• and, where necessary, assign individual responsibility.

Minimum requirement

AIFC auditability must support both system learning and responsibility.

36. Audit levels

AIFC may distinguish audit levels.

Level 0 - No audit required

Low-risk public or ad hoc activity.

Level 1 - Basic activity audit

Basic record of action, actor, and time.

Level 2 - Contextual audit

Record includes purpose, object, classification, and permission basis.

Level 3 - Governance audit

Record includes approval, decision context, AI involvement, lineage, and review.

Level 4 - Critical audit

Tamper-resistant, detailed, retained, and reviewable audit for Operational DNA, restricted AI processing, critical decisions, and high-risk agent actions.

Minimum requirement

The community must define audit level by risk, classification, and impact.

37. Audit scope

Audit scope must be clear.

Scope that is too narrow leaves gaps.

Scope that is too broad may create privacy, cost, or attention problems.

Scope should be governed by:

• classification,
• risk,
• agent autonomy,
• data sensitivity,
• decision criticality,
• external sharing,
• AI processing,
• legal/compliance needs,
• Operational DNA exposure.

Minimum requirement

Audit scope must be appropriate to risk and must not ignore critical AI and knowledge actions.

38. Audit privacy

Audit may contain personal and sensitive data.

It must respect:

• privacy,
• data minimization,
• role-based access,
• retention,
• redaction,
• legal requirements,
• employee trust,
• purpose limitation.

Auditability must not become an excuse for unlimited surveillance of people.

Minimum requirement

Audit must balance traceability, privacy, and trust.

39. Audit and vendors

Vendor actions must be auditable according to risk.

For AI vendors and external experts, it is important to audit:

• access,
• data processing,
• outputs,
• exports,
• derived knowledge,
• retention,
• subcontractor involvement,
• AI tool usage,
• deletion,
• knowledge return.

Minimum requirement

Vendor access to Restricted knowledge or Operational DNA must have auditable scope, purpose, and activity.

40. Audit and exit strategy

Audit supports exit strategy.

Without audit, the community may not know:

• what the vendor processed,
• what the agent created,
• where memory exists,
• what derived knowledge exists,
• which skills changed,
• which data must be exported,
• what must be deleted,
• what must be migrated,
• what must be reviewed.

Minimum requirement

A critical AI exit strategy must account for audit records needed for safe exit.

41. Audit and Human Cockpit Layer

The Human Cockpit Layer may show audit information in usable views.

It may show:

• recent critical changes,
• AI actions,
• pending approvals,
• access changes,
• export events,
• operating mode changes,
• agent incidents,
• boundary violations,
• unreviewed AI outputs,
• audit gaps,
• suspicious patterns.

The cockpit should not overwhelm.

It should make the important visible.

Minimum requirement

The Human Cockpit Layer or governance interface must make critical audit signals visible to responsible roles.

42. AI role in Auditability

AI may help with audit.

It may:

• summarize audit logs,
• find anomalies,
• detect scope drift,
• detect agent permission drift,
• prepare incident summaries,
• detect AI waste,
• detect repeated exceptions,
• propose validation rules,
• prepare review inputs.

However, AI must not close a critical audit of its own behavior without human or community responsibility.

Minimum requirement

AI-generated audit analysis must be marked as input or proposal and reviewed by a responsible role.

43. Suggested metadata

Example metadata for an audit event:

audit_event:
  id:
  timestamp:
  actor_id:
  actor_type: human | ai_agent | system | vendor | community | service_account
  actor_owner:
  action:
  object_type:
  object_id:
  object_classification:
  purpose:
  permission_basis:
  approval_id:
  ai_involved: true | false
  ai_tool:
  ai_model:
  agent_id:
  agent_permissions_id:
  operating_mode:
  autonomy_level:
  input_references:
  output_references:
  derived_knowledge_created: true | false
  export_performed: true | false
  external_sharing_performed: true | false
  result: success | failure | partial | blocked | escalated
  risk_level: low | medium | high | critical
  audit_level: 0 | 1 | 2 | 3 | 4
  retention_rule:

Example metadata for an audit policy:

audit_policy:
  id:
  title:
  status: draft | active | under_review | deprecated | archived
  owner:
  scope:
  applies_to:
    - access
    - ai_processing
    - agent_actions
    - source_of_truth_changes
    - approvals
    - decisions
    - exports
    - operating_mode_changes
    - incidents
  required_audit_level:
  prompt_output_logging:
    mode: full | redacted | metadata_only | hash_reference | none_with_controls
  retention_rule:
  log_access_rules:
  tamper_resistance_required: true | false
  human_review_required: true | false
  ai_analysis_allowed: true | false
  review_cycle:
  last_reviewed:

Example metadata for an audit finding:

audit_finding:
  id:
  title:
  status: observed | triaged | under_review | accepted | rejected | resolved | closed
  owner:
  finding_type:
    - missing_audit
    - unauthorized_action
    - insufficient_permission_basis
    - missing_approval
    - agent_scope_drift
    - ai_boundary_issue
    - export_issue
    - classification_issue
    - retention_issue
    - suspicious_pattern
  related_audit_events:
  affected_artefacts:
  affected_communities:
  severity: low | medium | high | critical
  proposed_action:
  related_change_proposal:
  created_at:
  closed_at:

These structures are illustrative.

The final schema should be defined in the agent-actionable layer of the standard.

44. Anti-patterns

AIFC rejects the following anti-patterns.

44.1 Logs without meaning

The system logs technical events, but the logs do not explain governance meaning.

44.2 AI action without trace

An agent performs an action, but it is not traceable why and under which permission.

44.3 Critical change without Decision Record

A critical Source of Truth or governance change has no decision record.

44.4 Approval without evidence

Approval exists, but it is unclear what was approved and why.

44.5 Export without audit

The knowledge base or Operational DNA is exported without a record.

44.6 Prompt/output black box

A critical AI workflow has no prompt/output audit policy.

44.7 Audit logs exposed

Audit logs are too broadly accessible and reveal sensitive know-how.

44.8 Audit logs editable by actors

Actors can change or delete their own audit trail.

44.9 Audit only for compliance

Audit is used only for formal compliance, not for learning and governance.

44.10 AI audits itself

AI closes an audit of its own critical behavior without human review.

44.11 No retention rules

Audit logs are either deleted too early or retained forever without reason.

44.12 No audit of permission changes

Permission changes are audited less than actions, even though they may be riskier.

45. Minimal requirements

An AIFC community must at minimum meet these Auditability requirements:

1. Meaningful actions over Restricted knowledge, Operational DNA, AI governance, Source of Truth, or decisions are auditable.
2. Auditability is understood as a foundation of trustworthy AI-first operation.
3. Audit records of critical actions are understandable and usable for review.
4. The community defines which action types require audit according to classification and impact.
5. A critical audit record identifies actor and actor type.
6. A critical audit record states action type.
7. A critical audit record identifies affected object or object scope.
8. Access to Restricted knowledge, Operational DNA, AI processing, and export has auditable purpose.
9. A critical action is traceable to permission basis or approval.
10. Approval of critical actions is auditable.
11. Actions over Restricted knowledge or Operational DNA audit data classification.
12. AI processing of non-public know-how is auditable according to sensitivity.
13. Critical AI workflows have defined prompt/output audit policy.
14. Autonomous or tool-using agents have an audit trail appropriate to risk.
15. Critical Source of Truth changes have change history and rollback path.
16. Critical decisions have a Decision Record with auditable reasoning.
17. Changes to access for Restricted knowledge, Operational DNA, or AI processing are auditable.
18. Export of Restricted knowledge or Operational DNA has an audit record.
19. Meaningful AI Operating Mode changes are auditable.
20. Increasing AI autonomy or expanding agent permissions is auditable.
21. Exceeding or granting an exception to a meaningful AI budget is auditable.
22. Meaningful incidents have an audit trail and post-incident review.
23. Fallback activation for a critical workflow is auditable.
24. Critical AI-generated artefacts have basic lineage.
25. Audit logs of critical actions have retention and protection rules.
26. Audit logs have access control, integrity protection, and classification appropriate to sensitivity.
27. Audit records of critical actions are protected against unauthorized change or deletion.
28. Responsible roles have human-readable access to audit information for critical areas.
29. AI access to audit logs is explicitly governed and limited by sensitivity.
30. Repeatable critical audit checks become validation rules when practical.
31. AI Retrospective has access to relevant audit inputs according to scope and sensitivity.
32. Compliance audit is complemented by learning and governance audit in critical AI-first areas.
33. Auditability supports both system learning and responsibility.
34. The community defines audit level by risk, classification, and impact.
35. Audit scope is appropriate to risk and does not ignore critical AI and knowledge actions.
36. Audit balances traceability, privacy, and trust.
37. Vendor access to Restricted knowledge or Operational DNA has auditable scope, purpose, and activity.
38. Critical AI exit strategy accounts for audit records needed for safe exit.
39. Human Cockpit Layer or governance interface makes critical audit signals visible.
40. AI-generated audit analysis is marked as input or proposal and reviewed by a responsible role.

46. Summary

Auditability gives an AI-first community a memory of responsibility.

It is not enough that the system works.

The community must know:

• what happened,
• who or what did it,
• why,
• under which permission,
• with which data,
• what role AI had,
• who approved,
• and what follows from it.

AIFC therefore states:

Make critical actions traceable.
Make AI actions explainable.
Make decisions reviewable.
Make learning possible.

Auditability is not only control of the past.

It is the community’s ability to learn, correct itself, and govern its future with trust.

Auditability turns action history into accountable and learnable governance.