Usage Policy

1. Purpose and scope

This policy merges the Acceptable Use Policy (AUP) and System Policy for all LogiHash components (web, app, API, reporting) and T-Code metadata workflows.

2. Permitted use

Use is limited to legitimate creation, management, and verification of T-Code-based business processes.

3. Prohibited use

• •Security bypass attempts, load/stress attacks, credential sharing
• •Creation or distribution of misleading or false verification content
• •API abuse and automated scraping without authorization
• •Abuse of reporting and feedback channels

4. Minimum metadata requirement

Users must provide at least four meaningful, descriptive, document-related metadata fields for each production T-Code.

• •Recipient name
• •Final invoice amount
• •ID number
• •Final grade of a certificate
• •Unique reference data (e.g., process or reference ID)

5. Quality, uniqueness, and data minimization

• •Metadata must be truthful, verifiable, and context-specific.
• •Do not include unnecessary personal data.
• •Do not store secrets, credentials, or key material in plaintext.
• •Avoid generic metadata that cannot clearly distinguish one process from another.

6. Key-related prohibitions (key harvesting)

• •Systematic collection/extraction of DEK- or key-related T-Code components
• •Building correlation databases from such components
• •Automated reuse outside approved verification processes

7. Verification and key resolution

Public keys may only be resolved through approved KID-based API processes for legitimate verification purposes.

8. AI-assisted risk signaling

The system may use AI models to assess metadata plausibility, detect unusual patterns, and prioritize risks. AI indicators do not replace human approval for critical document classes.

9. Reporting, audit, and responsibilities

• •Reported T-Codes/metadata are reviewed through technical and organizational controls (including smart triage).
• •Customers must assign data owners per business domain.
• •Metadata schemas, field definitions, approvals, and schema changes must be versioned and audit-ready.

10. Technical reference (T-Code structure)

• •Full (270 chars): Version(2) + CreatorID(7) + DBEntryID(17) + DEKMaterial(50) + KID(20) + PolicyFlags(2) + FullSignature(86) + HeaderSignature(86)
• •Verification (134 chars): Version(2) + CreatorID(7) + DBEntryID(17) + KID(20) + PolicyFlags(2) + HeaderSignature(86)
• •FullSignature is used for full mobile verification; HeaderSignature for header/API-near verification paths

11. Enforcement and consequences

• •Depending on severity: warning, technical restriction, rate limit, temporary or permanent suspension
• •For severe or repeated violations: contractual actions up to termination
• •For suspected false identity documents: immediate risk assessment, process freeze, and possible reporting to competent authorities within legal boundaries

12. AdES usage (advanced electronic signatures)

• •Where AdES features are provided, signature triggering, role/identity assignment, and verification are permitted only for lawful business workflows.
• •Customers remain responsible for assessing whether AdES is legally sufficient for a specific case or whether a higher signature level is required.
• •Unauthorized signature triggering, abusive signature checks, or manipulation of verification evidence is prohibited.