Transform mockusign_dbt into realistic dbt project with staging/marts

Problem

The reference e-sign dbt used for demos and pack development should read like a deliberate Nimble-shaped project, not a flat folder of models. That does not mean “no staging” — Fivetran quickstarts already introduce per-source staging; the gap is making our in-repo example follow the same idea clearly, then land in one unified analytics schema (single integrated layer analysts and dashboards target) instead of ad hoc models or an unnecessary proliferation of intermediate/mart namespaces.

Without that contract (staging → unified core), connector dashboard packs and pilot walkthroughs stay anchored to shapes that don’t match how we want teams to think about the warehouse, and it’s harder to show that packs port to real customer projects.

Context

• Nimble as the modeling reference: nimble/ in this repo (principles, practices, tutorials — draft / on hold but still the intended vocabulary).
• Layering target: staging (source- or connector-scoped, aligned with quickstart patterns) → one unified schema for facts/dims the business consumes; add intermediate only where the graph truly needs it, not as boilerplate.
• Repo reality: examples/mockusign_dbt/ may be gone after faketran/dundersign promotion — if so, apply this task to the designated canonical example (e.g. examples/dundersign_dbt/) and treat “mockusign” as the product archetype, not a path requirement.
• Seed/test/doc coverage should support onboarding; dashboards should resolve against the unified layer + documented staging contracts.
• Done when: dbt build is reliable, docs/tests/freshness exist where they teach the contract, and quickstart-linked dashboards map cleanly to the unified layer (staging only as the obvious on-ramp from sources).

Possible Solutions

• A - Keep the current flat project and rely on narrative explanation: easier now, but weak as a realistic reference.
• B - Recommended: refactor the project into a realistic staging and marts shape with deliberate model layering and docs.
• C - Replace the example entirely with a different project: possible, but throws away existing work unnecessarily.

Plan

• Inventory target tree (dundersign_dbt or agreed canonical example); align folder/schema naming with Nimble practices where they apply.
• Ensure per-source staging matches quickstart expectations; build one unified analytics schema (explicit schema/dataset contract) as the default dependency for faces/packs.
• Add intermediate only for real refactors (not a mandatory third layer); document the graph in schema.yml / README.
• Add source freshness, tests, and docs that explain staging → unified.
• Update example dashboards / pack YAML to point at the unified layer; validate dbt build + Dataface render from clean checkout.
• Capture migration notes for tutorials and any lingering mockusign references.

Implementation Progress

• GitHub issue: https://github.com/fivetran/dataface/issues/306

Review Feedback

• [ ] Review cleared